Microservices with Kubernetes

Short Summary

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.

Long Summary

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.


1 -) 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?

Continue reading

Session Manager – Modern Bastion


Are you tired of dealing with key pairs? Maybe tired of securing them with KeyPass? Or configuring SSH daemon for ease of use? Don’t worry, Systems Manager – Session Manager is here to save you from all these.

Session Manager is announced on 11 September 2018 with this blog post. Seriously, I remember being excited like potatoes thrown into hot oil. Because the process for connecting RDS Instances via Bastion Hosts were literal pain in our workplace. All those SSH private keys, security of them, jumping one from another for again, security reasons… All I can say is, it was taking long.

At this point, you might say, “Why aren’t you using a third party UI such as Bastillion EC2 for connecting Instances?” That’s because there are intermediate EC2 Instances  involved with jump process. Complexity is already high, no need to increase it.

Now, you might also say, “But you know you can use a tool to add people’s IP to the security group of the Instances when they try to connect? Then let’s say, after 12 hours, you might remove the IPs from the security group.” For curious cats, it is explained in this Medium Story. That’s an option for sure, but I don’t like the idea of changing the state of a resource that much. Needlessly to say, we want immutable infrastructure in the end, right?

Continue reading

The Ultimate DevOps Explanation

Dream Has Come True!

I am a person who believes that if someone wants to do a successful job, they first need to understand what the job is fundamentally. I love how Albert Einstein put it as he states:

If you can’t explain it simply, you don’t understand it well enough.
– Albert Einstein

With that being said, I consider Amazon’s DevOps definition as a simple yet amazing definition. It describes DevOps in a rough way but also covers nearly everything. Although, it needs some elaboration.

From what I’ve seen, ~99% of the definitions on the internet don’t cover up everything related to DevOps. Let’s be ~1%.

If you know what DevOps actually is, you will start seeing things from a different, constructive, rewarding and top-view perspective and contribute even more to your team.

Continue reading

Creating Cloudwatch Dashboards per Environment with Python

Show Me The Code Already

After installing Cloudwatch Agent to the machines you want to monitor, it’s time to create dashboards to view real-time metrics.

There are some ways to create Cloudwatch Dashboards such as creating them manually by selecting widgets from AWS Console, with Cloudformation etc.

I’ve decided to create them with Python because in DevOps literature, there is no such a thing as manually creating something. I also didn’t want to use Cloudformation because I like scripting and we have many applications to monitor in our company, thus, I needed something to iterate over our environments and create dashboards for each of them.
Continue reading