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?





An operation model for building cloud native applications.


GitOps is a way to do Continuous Delivery.  It works by using Git as a single source of truth for declarative infrastructure and applications. With Git at the center of your delivery pipelines, developers can make pull requests to accelerate and simplify application deployments and operations tasks to Kubernetes.

GitOps can be summarized as these two things:

  1. An operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for containerized clusters and applications.
  2. A path towards a developer experience for managing applications; where end-to-end CI/CD pipelines and git workflows are applied to both operations, and development.


4 -) What are the Design Patterns for Microservice Architecture?



There are five main microservice design pattern categories including:

  1. Decomposition Patterns
  2. Integration Patterns
  3. Database Patterns
  4. Observability Patterns
  5. Cross-Cutting Concern Patterns


You’ll hear about Aggregates, CQRS and Event Sourcing Pattern the most. These patterns solve generic problems.


5 -) What is REST?




REST is Representational State Transfer and it’s a software architectural style about communication. REST’s main goal is to provide interoperability between computer systems on the Internet while supplying:

  • performance in component interactions, which can be the dominant factor in user-perceived performance and network efficiency,
  • scalability allowing the support of large numbers of components and interactions among components,
  • simplicity of a uniform interface,
  • modifiability of components to meet changing needs (even while the application is running),
  • visibility of communication between components by service agents,
  • portability of components by moving program code with the data,
  • reliability in the resistance to failure at the system level in the presence of failures within components, connectors, or data.


REST’s advantages are; usage of HTTP status codes, encryption by TLS instead of dedicated frameworks, language independency and pervasiveness.

REST’s disadvantages are; stateless architecture and inability to send push notifications from server to client which is solved by webhooks (This is solved with HTTP/2).


6 -) What are the differences between REST vs SOAP?


ELI5: What is the difference between REST and SOAP? from explainlikeimfive


SOAP is Simple Object Access Protocol. While SOAP is a protocol and have a standard, REST is a set of principles, thus, it doesn’t have any standards.


A comment from Reddit:

SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are both ways to pass messages between computing processes over the Internet.

SOAP, which has been around for much longer, uses an XML payload to pass the messages. That XML payload can be delivered over the web (HTTP), but it can also be delivered via different protocols, such as those for email (SMTP).

So, think about it like a package you’re sending to your buddy. They need to act on the instructions in your package. With SOAP, you have to construct those instructions in a rigid, detailed manner as an XML file and put it in a box and send it to your buddy. He then has to open the box, decipher those instructions, and act on them.

REST is much lighter weight. With REST, the messages are usually encoded as part of the URL, so a payload isn’t absolutely necessary (though possible, of course). So a lot can be done with the usual HTTP methods of GET, POST, PUT, and DELETE. You can only use HTTP, though.

Think of REST this way: instead of having to create a bunch of instructions and package them up in a box, you just include the instructions as another line in the address (the URL) on the outside of the box itself. When you send that to your buddy, it’s less work for them because they don’t have to deal with opening the box, figuring out what’s inside, and deciphering all those instructions.

That’s way oversimplifying, but it’s a start.

Also, more differences:

  • REST API has no official standard at all because it is an architectural style. SOAP API, on the other hand, has an official standard because it is a protocol.
  • REST APIs uses multiple standards like HTTP, JSON, URL, and XML while SOAP APIs is largely based on HTTP and XML.
  • As REST API deploys multiple standards, so it takes fewer resources and bandwidth as compared to SOAP that uses XML for the creation of Payload and results in the large sized file.
  • The ways both APIs exposes the business logics are also different. REST API takes advantage of URL exposure like @path(“/WeatherService”) while SOAP API use of services interfaces like @WebService.
  • SOAP API defines too many standards, and its implementer implements the things in a standard way only. In the case of miscommunication from service, the result will be the error. REST API, on the other hand, don’t make emphasis on too many standards and results in corrupt API in the end.
  • REST API uses Web Application Description Language, and SOAP API used Web Services Description language for describing the functionalities being offered by web services.
  • REST APIs are more convenient with JavaScript and can be implemented easily as well. SOAP APIs are also convenient with JavaScript but don’t support for greater implementation.


7 -) On which servlet container does Spring Boot run?



By default, Tomcat. It is included by default when using spring-boot-starter-web.


On startup, it is found that the memory footprint of Tomcat, Jetty, and Undertow was comparable with Undertow requiring slightly more memory than the other two and Jetty requiring the smallest amount.

For benchmark, it is found that the performance of Tomcat, Jetty, and Undertow was comparable but that Undertow was clearly the fastest and Jetty only slightly less fast.

This table represents bare-bone application. You certainly need to benchmark your own application if you want to be more precise and accurate.


8 -) What are the important release notes of Spring Boot 2?



Spring Boot 2 needs at least Java 8 to run. Upgraded libraries:

  • Tomcat 8.5
  • Flyway 5
  • Hibernate 5.2
  • Thymeleaf 3

Spring Boot 2 now supports Reactive Applications, HTTP/2, Kotlin 1.2, JSON Plugin(spring-boot-starter-json). Some improvements on Gradle, Hibernate, Redis are made. Actuator endpoints are changed. Instead of its own metric API, Spring Boot now relies on micrometer.io.


9 -) What is GRPC?




GRPC(Google Remote Procedure Call) is an alternative to REST. GRPC uses Probuff instead of JSON as payload format. Protobuff is a packed format and more efficient than JSON which is a text based format. GRPC uses HTTP/2 by default and benefits from it. HTTP/2 is in binary format, uses multiplexed streams to send request without establishing a new TCP Connection and can push notifications from server to client. (More explained in above link)


10 -) What is Docker Multistage? How does it help with Docker Image efficieny?






Docker Multistage lets you reduce complexity and resource usage(image size) and provides artifact/dependency linkage. For example, without multistage, if you want to pass an artifact to another Dockerfile, you’d need to pass them via local filesystem. With multistage, you can reference previous stage’s artifacts and use them in later stages. Previous stages will be thrown away when the build job is finished.


Example multi-stage Dockerfile:

# ---- Base Node ----
FROM alpine:3.5 AS base
# install node
RUN apk add --no-cache nodejs-current tini
# set working directory
WORKDIR /root/chat
# Set tini as entrypoint
ENTRYPOINT ["/sbin/tini", "--"]
# copy project file
COPY package.json .
# ---- Dependencies ----
FROM base AS dependencies
# install node packages
RUN npm set progress=false && npm config set depth 0
RUN npm install --only=production 
# copy production node_modules aside
RUN cp -R node_modules prod_node_modules
# install ALL node_modules, including 'devDependencies'
RUN npm install
# ---- Test ----
# run linters, setup and tests
FROM dependencies AS test
COPY . .
RUN  npm run lint && npm run setup && npm run test
# ---- Release ----
FROM base AS release
# copy production node_modules
COPY --from=dependencies /root/chat/prod_node_modules ./node_modules
# copy app sources
COPY . .
# expose port and define CMD
CMD npm run start


11 -) What is the difference between COPY and ADD commands?



COPY takes in a src and destination. It only lets you copy in a local file or directory from your host (the machine building the Docker image) into the Docker image itself.

ADD lets you do that too, but it also supports 2 other sources. First, you can use a URL instead of a local file / directory. Secondly, you can extract a tar file from the source directly into the destination.


12 -) What is jib?



Jib builds optimized Docker and OCI images for your Java applications without a Docker daemon – and without deep mastery of Docker best-practices. It is available as plugins for Maven and Gradle and as a Java library.


  • Fast – Deploy your changes fast. Jib separates your application into multiple layers, splitting dependencies from classes. Now you don’t have to wait for Docker to rebuild your entire Java application – just deploy the layers that changed.
  • Reproducible – Rebuilding your container image with the same contents always generates the same image. Never trigger an unnecessary update again.
  • Daemonless – Reduce your CLI dependencies. Build your Docker image from within Maven or Gradle and push to any registry of your choice. No more writing Dockerfiles and calling docker build/push.


13 -) What is Quarkus?



Quarkus is a Cloud Native, (Linux) Container First framework for writing Java applications.

Quarkus tailors your application for GraalVM and HotSpot. Amazingly fast boot time, incredibly low RSS memory (not just heap size!) offering near instant scale up and high density memory utilization in container orchestration platforms like Kubernetes. We use a technique we call compile time boot.


14 -) What is kubectx?



kubectx is a utility to manage and switch between kubectl(1) contexts.


15 -) What is Weavescope?



Weavescope helps you to understand your application quickly by seeing it in a real time interactive display.

Weave Scope automatically detects processes, containers, hosts. No kernel modules, no agents, no special libraries, no coding. Seamless integration with Docker, Kubernetes, DCOS and AWS ECS.


16 -) What is Cloud Native Foundation?




CNCF is a community and collection of standards which is sustaining and integrating open source technologies to orchestrate containers as part of a microservices architecture.

Leave a Reply