Win a copy of Java Challengers this week in the Java in General forum!

Stepankha Yuliannia

Greenhorn
+ Follow
since Mar 24, 2021
Stepankha likes ...
Java ME Quarkus Java
Stepankha Yuliannia, PhD.
Germany
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
1
Total given
1
Given in last 30 days
1
Forums and Threads

Recent posts by Stepankha Yuliannia

Congratulation to all the winners.
3 weeks ago
I wouldn't say "never makes sense to use cloud PaaS". Let me put it this way - if you are not ABSOLUTELY required to use specific PaaS from one of the cloud providers (due to various reasons like compliance, monitoring tools lock-in, data lock-in, networking lock-in etc.), it is often times better to use multiple providers:
1) Because no single cloud service provider has the best tools for everything - by using multiple cloud service providers or an abstraction layer above these providers, you can cherry-pick the best services from each.
2) Depending on one provider for any product or service can be risky. Not only might they suffer an outage, but their service levels could decline or their prices could go up (theoretical, but possible). By not putting all your eggs in one basket, you are minimizing the risk of your own business suffering in the future.
3) Another benefit of that could be, if you are a high-volume customer (e.g. a million $$$ or more per year), you may be in a position to negotiate lower prices.
3 weeks ago
From the CI/CD perspective, I don't think it makes much difference whether it is legacy or brand new (if by legacy, you mean systems that do not have automated test as it is provocatively defined in Michael Feather's book "Working Effectively with Legacy Code") codebase. The same principles still apply - you need to achieve certain level of maturity in various levels of your software delivery as I explained in the other thread here: https://coderanch.com/t/741354/engineering/Pipeline-Code-Practices-CI-CD.

The first priority when dealing with such a system is usually to create an automated build process if one does not exist. Then maybe the next priority would be to create an automated functional functional test scuffolding around it. Creating automated tests will be easier if documentation or the team members are still available (might not be the case). This activity could be hard as from the business perspective, you're spending time on what seems like "low-value activity" - if the legacy system is already in production and working "fine". Once these smoke tests are in place, you can begin with layered approach to your automated tests. The first layer being very simple and fast-running tests for problems that prevent you from doing useful testing and development on whatever functionality you are working on. The second layer tests the critical functionality for a particular feature. This can sometimes be harder that it sounds. Systems designed to be testable tend to be more modular and easier to test thant those that are not. However, this should not divert you from the goal. It is important to remember, that you should only write automated tests where they will deliver value - the vast majority of regression bugs are caused by altering framework code, so if you are only adding features that do not require changes to the underlying framweork, there is little value writing a comprehensive scuffolding (however, the exception to this is when your sofware has to run in a number of different environments - in this case automated tests combined with automated deployment to production-like environments deliver a gread deal of value since you can simply point your scripts at the environments to be tested and save yourself a lot of effort on manualt testing).

Good luck!
3 weeks ago
When your organization is already "locked-in" to the specific provider's container PaaS and has all data and other supporting infrastructure on that provider, it makes sense to keep using that cloud PaaS. However, when you are talking about greenfield project and starting from scratch, it would probably be a smart decision to use some abstraction layer like OpenShift/Rancher/CloudFoundry which will make it more future proof and will allow you to move more freely between various platforms.

I found this article which explains it really well: https://www.overops.com/blog/pivotal-cloud-foundry-vs-kubernetes-choosing-the-right-cloud-native-application-deployment-platform/
4 weeks ago
Hi,

Some people are opinionated about this - but I would like to hear your view on when to use Jenkins Scripted Pipeline and when it is better to use Jenkins Declarative Pipeline.

Kind regards
4 weeks ago
The author may have a different opinion on this, but I would still use CI if more than 2 people are involved in touching the same codebase and potentially "stepping on each other's toes". Even if you implement simple workflow like "You push your code to GitHub" -> "GitHub triggers CI to test & build" -> "Your build passed!", it immediately gives you more efficiency without much expertise. For this simple scenario, I would probably use something like Travis CI if you don't want to manage another tool in your arsenal.
4 weeks ago
When comparing CNIs, you are essentially comparing the speed/throughtput and when comparing CRIs you are concerned about security differences.
Look at these two links:
Comparing CNIs
Comparing CRIs

My personal preference is Flannel + CRI-O
4 weeks ago
This is very broad question. CI and CD are also two very different things. The practice of CI relies on certain prerequisites being in place. You need git, you need automated build and everyone in the team must be on board. When this is in place, you need to check in regularly, you need to keep the build and test process relatively short and you need a tool that simplifies these steps for the team.
As for the CD, you need even more maturity. You want to use configuration management across all of your environments and have proper deployment pipeline in place. It also depends on very effective collaboraton between everyone invo9lved in the delivery. All of these roles must be mature enough for you to be successful at CD:
1. Practice
2. Build management and already mature CI
3. Configuration management
4. Environments and deployment
5. Release management (and usually also compliance)
6. Testing
7. Data management

Good luck!
4 weeks ago
Hi Akash,

I don't fully understand what is it that you are asking. Container Network Interface (CNI) and Container Runtime Interface (CRI) are basically extensions into Kubernetes API. Are you asking about pros and cons of different CNI plugins (e.g. Calico, Flannel) and different CRI plugins (e.g. Docker, CRIO)?
1 month ago
Hi,


In CHAPTER 6 DEPLOYING HA JENKINS ON MULTIPLE CLOUD PROVIDERS you are giving examples how to create master Jenkins golden image and launch auto-managed workers on each provider separately (by the way I don't believe the note about GCP charging you per 10 minutes is correct - I could be wrong, but I think both providers now charge you by the minute, rounded up to the nearest minute). Would you mind elaborate on managing workers in different environments simultaneously (e.g. Kubernetes plus AWS plus Azure etc.)?

Best regards,
1 month ago
Hi,


I have been using cloud-native CI/CD called Tekton (https://tekton.dev/) which concept is being Kubernetes-ready and entirely running as pods. Can you give some recommendations and best practices building and running "containers inside containers"? I understand there are some security concerns, but this relatively new tool runs a task in the form of a Kubernetes pod, where each step becomes a running container in the pod so when you are building images, you are essentially building them inside containers.


Many thanks for the further discussions about this topic.
1 month ago
Hi Mohamed, welcome to Coderanch. Looking forward to discuss some interesting topics.
1 month ago
Well done, congratulations to all three of you!
1 month ago
CloudFoundry is natively multi-cloud, so if you run on PaaS from one specific cloud provider, you are essentially locking yourself into this provider. By using CloudFoundry, you are creating an "abstraction layer" on top of multiple providers.

>From WiKi: This multi-cloud environment allows developers to use the cloud platform that suits specific application workloads and move those workloads as necessary within minutes with no changes to the application.
1 month ago
Hi Monica,

If it is a newly established team and the dynamics of the team and the velocity is unknown, it is a good practice to start estimating using the "T-shirt" sizing (XS, S, M, L, XL, XXL) before you move on to Fibonacci estimation.