This was a three days training where Murat Karakaş explained;
- what Microservices are,
- what Spring Boot is,
- what Kubernetes is,
- how they combine,
- what best practices are with them.
I took some notes meanwhile and I’m going to research the topics, provide notes, links to understand the training completely. I noticed that there are many new technologies out there and I believe it’s for my benefit to research these technologies and have it written here.
We can think this as a notebook for the training.
Questions1 -) Are microservices always a viable, feasible solution?
Well architected monolith is better than a hodgepodge of duct tape.
There is no silver bullet. Although generally microservices provide better functionality, monoliths are not dead and there are cases where it’s best to use monoliths. It’s also easier to transform monoliths to microservices but not the other way around.
When To Start With A Monolith
- Your Team Is At Founding Stage: Your team is small, between 2–5 members, and is thus unable to tackle a broader and high-overhead microservices architecture.
- You’re Building An Unproven Product or Proof of Concept: Are you building an unproven product in the market? If it’s a new idea, it’s likely going to pivot and evolve over time, so a monolith is ideal to allow for rapid product iteration. Same applies to a proof of concept where your goal is just to learn as much as possible as quickly as possible, even if you end up throwing it away.
- You Have No Microservices Experience: If your team has no prior experience with microservices, unless you can justify taking the risk of learning “on the fly” at such an early stage, it’s likely another sign you should stick to a monolith to start.
- You are required to build MVP ASAP: Sometimes you are required to build your minimum viable product as soon as possible. Since there are less operational overhead, monoliths tend to be built faster.
- You don’t have the budget: When you didn’t get millions in investments to hire DevOps or spend extra time on complex architecture.
- You don’t have a hot service/bottleneck: When you have a hot service, you will want to isolate and scale them without touching other services. If you don’t have any bottleneck services, there is almost no point to separate them because they go along with other parts.
When To Start With Microservices
- You Need Quick, Independent Service Delivery: Microservices allow for fast, independent delivery of individual parts within a larger, integrated system. Note that, depending on your team size, it can take time to see service delivery gains versus starting with monolith.
- A Piece of Your Platform Needs to Be Extremely Efficient: If your business is doing intensive processing of petabytes of log volume, you’ll likely want to build that service out in a very efficient language (i.e. C++) while your user dashboard may be built in Ruby on Rails.
- You Plan To Grow Your Team: Starting with microservices gets your team used to developing in separate small services from the beginning. And having teams separated by service boundaries makes it much easier to scale up your team when you need to without introducing exponential complexity.
- You don’t have a tight deadline: Microservices require you to research and architecture planning to ensure it works.
- You have a team with knowledge of different languages: By knowing different languages’ capabilities, you can use them for specific domains. This way, you can have benefits of different languages.
- You worry a lot about the scalability and reliability of your product: When using microservices, you can configure each service’s scaling mechanism by their own requirements.
- You have an existing monolith app and see problems with parts of your application: Maybe the problems can be solved by separating monolith to microservices.
2 -) What is 12-Factor App and is it still relevant?
It is a manifest which defines 12 main factors to build an ideal application. And yes, it is still relevant (Check the video above).
The twelve-factor app is a methodology for building software-as-a-service apps that:
- Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
- Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
- Minimize divergence between development and production, enabling continuous deployment for maximum agility;
- And can scale up without significant changes to tooling, architecture, or development practices.
3 -) What is GitOps?