How To Start Using Microservices

Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software architecture. More and more developers are adopting it.

Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications. Companies all over the world have recognized the advantages they get with microservices. Amazon, Netflix, eBay, Spotify, Uber, Groupon, and SoundCloud, are only some of them.

Here, we made a summary of everything you need to know about microservices in order to get started. These are the topics we’ll discuss:

• What are Microservices?
• Monolithic vs. Microservices Architecture
• Why choose Microservices?
• Challenges of Microservices
• Microservices and Docker
• Microservices and Kubernetes
• Building Microservices architecture
• When to use Microservices?

What are Microservices?

Using microservices means creating applications from loosely coupling services. The application consists of several small services, each representing a separate business goal.

They can be developed and easily maintained individually, after what they are joint in a complex application. You can also use different programming languages, like Node.js, Java, PHP, etc.

Microservices give dev teams the freedom to choose the technology stack they prefer best. They release them from worries about the effects it will have on the app they’re developing. This allows them to operate much faster and have more confidence than when they work with a monolithic architecture.

However, this doesn’t mean that we should completely eliminate and forget monolithic architecture. Many companies are still struggling when it comes to choosing the type of architecture they should use — monolithic or microservice.

So, let’s see what’s the difference.

Monolithic vs. Microservices Architecture

Having a monolithic architecture means creating a single unit as the base for all the functional components. This includes database operations, business logic, background processing, etc. They are all deployed at once and run on the same servers.

Everything is in one single codebase, where all the updates are made. This makes scaling tricky, as the application becomes too complex to handle. Adding more features becomes a bigger problem when the codebase is larger. This limits flexibility and leaves no space for new ideas.

Monolithic architecture means that the processes are tightly coupled. If there is a problem with only one of them, the entire architecture goes down. This is very risky because the entire application can fail due to one small mistake.

On the other hand, the microservice architecture consists of separate services instead of a single unit. These services represent separate codebases that communicate through APIs. As every service represents a separate function, you can also update, deploy, and scale it independently. This doesn’t affect the rest of the microservices.

Monolithic architecture is better when:

• the application you’re developing is simple, and everything is in the same language and framework,
• you want to test quickly and easily by simply launching the application, and
• you don’t have too many new features that will trigger the release of the entire application.

Why choose Microservices?

There are several reasons why microservices are better for your application:

Scalability

In the microservices architecture, every service scales separately from the others. This means that every feature functions independently, allowing teams to choose the most suitable technology stack. Moreover, they can estimate costs for each feature, and modify it when needed.

Productivity

Microservices are definitely the way to go for large teams. As they work on large projects that take up too much time and effort, the microservices approach allows teams to split them into several independent services.

These services function independently. This means that team members will be able to work on the same project without a great need for coordination. Teams working on a particular microservice can make decisions on their own, without having to wait for the others. For starters, they’ll have the freedom to choose the language they want to write a microservice in. They don’t have to coordinate with the tech stack other teams are using.

Agility

Being agile is what most of today’s dev teams strive for. Microservices architecture allows a large team to split into several smaller teams responsible for separate services. This gives them autonomy, as well as the possibility to be more efficient by working through a shorter development cycle.

Reusability

Working with microservices means having small pieces of code that are paired into a large application. These pieces that represent different features of the application can also function independently. This means that you can use them as a base or an addition to another feature. Developers save a lot of time because they don’t always have to write the code from scratch.

Moreover, all these parts can be replaced. So, if a feature of the application becomes outdated, it can easily be re-written and re-added. This doesn’t disrupt the functioning of the entire application. You can always make changes according to team goals and performance.

Challenges

Before you decide to migrate to a microservices architecture, you should also know the challenges that might occur:

Complexity of communication

Now that the application consists of several different services that function independently, communication between them should be carefully set. There will be requests between the modules that developers have to handle. They also may have to add some additional code to keep the flow going. If the number of microservices is large, communication between them can cause many complications.

More effort required

Unlike monolith architecture where everything’s in the same unit, microservices have more databases that require better transaction management. What is more, each independent unit has to be separately deployed and monitored. This means that the team will have to spend time and effort in monitoring and getting each separate service ready for deployment.

Testing multiple units

In the monolith approach, you only need to launch the single unit you have on the server and make sure it’s connected to the database. Now that you have more services and databases, you have to confirm each of them separately before you can test the entire app. In some cases, one of the services can block the test stage and stop the deployment of the rest of the services.

This means that microservices require more testing time. You’ll have a lot of interfaces to test, and every testing process has to be done separately from the others.

Aside from all these disadvantages, it’s very important to state that the right kind of automation, tools, and developers who are rockstars in their areas every challenge can be solved.

Docker

Microservices are usually deployed in containers — virtual operating system environments that act as packaging for the microservices.

Docker is one of the most popular container solutions. Docker is a lightweight system of virtual machines that helps developers manage and deploy microservices more efficiently.

With Docker, every microservice is placed in a Docker image and a Docker container. These pieces are completely independent of the host environment.

Docker replaces the need for having your own virtual operating system environment by sharing the kernel of the operating system on its Docker host.

Docker allows microservices to be split into even smaller pieces of code and created as Docker images through files named Dockerfiles. These Dockerfiles make linking microservices into a large application much easier.

Microservice systems are usually built of several Docker containers, which are coordinated through the virtual network. As containers have to communicate, Docker has built the Docker Compose environment which allows communication between servers.

Docker is often mixed up with Kubernetes. However, these two aren’t competitors. In fact, their combination can lead to better results. Let’s break this down.

Microservices and Kubernetes

Kubernetes ( k8s or “kube”) is an open-source system for automating the deployment, scaling, and management of containers. It was first developed by Google engineers. Since then, Google runs everything in containers and generates over 2 billion container deployments every week.

Developers are massively adopting Kubernetes in order to make their lives easier. They connect through a Kubernetes community that counts thousands of contributors and many certified partners.

By merging together groups of running containers, Kubernetes creates clusters that can be easily managed. You can manage these clusters in all kinds of clouds, including public, private, and hybrid. That’s why Kubernetes is used to host cloud-native applications that are set to scale very quickly.

So, Kubernetes isn’t an alternative to Docker. Neither does Docker replace Kubernetes. They can both run independently. However, when paired, they can have great benefits from each other.

Docker is a software that you install on your computer and run containerized applications with. If you have Docker installed on your computer, you can use Kubernetes to automate container operations like management, networking, security, scaling, etc. You can do this if your Docker is installed on several Docker hosts or nodes.

A set of nodes managed by Kubernetes is called a Kubernetes cluster.

There are many things you can do with Kubernetes:

• Split the app into small containers run on different cloud environments
• Integrate and orchestrate containers
• Manage codebases and test separate inputs and outputs efficiently
• Scale apps in no-time and gain faster time-to-market
• Migrate from one to another hosting vendor without having to make major changes in your processes
• Use a configuration file so you can be sure that your applications are running exactly according to your specifications. You can manage them declaratively.
• Automatically restart, replicate, and scale apps making them capable to heal independently

Building Microservices architecture

You can build microservices in a number of different frameworks. Here are the most popular ones:

• Spring Boot with Spring Cloud — a Java framework with various extensions for full stack microservices on the Spring Cloud.
• Vert.x — a tool that runs on the JVM, allowing you to choose your language and providing simple APIs.
• Akka — an actor-based framework that’s perfect for reactive microservices.
• Quarkus — a Kubernetes Native Java framework for building modular microservices applications.
• Falcon — a Python framework focused on quality control and optimized for microservices.
• Molecular — a microservices framework for Node.js that supports event-driven architecture.

How to deploy microservices?

There are several options. You can also combine some of them.

• On the cloud, to gain the ability to scale and serve a lot of users from different locations
• With containers, to reduce time-to-market, scale easily, and solve issues quickly
• As PaaS (Platform-as-a-Service), renting development tools, infrastructure, and operating systems from a cloud provider
• Serverless, when large traffic is expected, and by
• Building your own IT infrastructure if you have the resources to perform this.

What cloud provider to use?

Here are some of the options:

• AWS has a large number of services and is suitable for almost any kind of technology.
• Azure is the best solution for .NET stack, helping in development, data storage, and hosting solutions.
• Google Cloud Platform solves issues with accessible AI & data analytics and has great support for Kubernetes.
• Digital Ocean supports both one-click apps and standard distribution, with flat pricing across 8 data center regions.

How to monitor microservices?

There are many tools you could use. Here are some suggestions:

• Datadog — we use it for monitoring, tracing log analytics, and alerting. It’s very effective when it comes to bug detection and performance degradation.
• Dynatrace — AI-powered platform for monitoring dynamic, hybrid cloud environments.
• NewRelic — a centralized monitoring and reporting tool for cloud environments.
• Splunk — a flexible tool for logs analysis.
• AppDynamix — real-time monitoring of app and server performance.
• Zabbix — an open-source network for performance monitoring.

How to automate the CI/CD process?

• Microtica covers the entire software delivery automation process from a complete cloud infrastructure setup to delivering applications and services in the cloud using Kubernetes. Microtica standardizes the way our developers develop, test, and deploy code in the cloud. It makes their work reusable for future projects.

What to test with?

Here’s what we use:

• Mocha + Chai for unit integration testing and
• Postman for API testing automation. We define a test case for each of our public APIs. We execute them at the end of every day and get reports immediately. When a problem occurs, we fix it right away and deploy to production.

Microservices practices

There are many practices, but let’s see some of the most common ones:

• Micro Frontends — monolith web interfaces are separated into several independent components that communicate as microservices
• Continuous Delivery — if you need to change only one feature without touching the rest
• Domain-driven Design — solving the challenges of tightly-coupled microservices
• Database per Service — although this requires more communication between teams, a database in each microservice brings more sustainability

When to use Microservices?

Microservices architecture is the best solution when:

• you have many new features coming up,
• you’ll be releasing features often,
• you have many subdomains,
• your company is planning to grow,
• you have a large team that can work on different microservices at the same time,
• or you have agile, cross-functional teams that collaborate on large projects.

However, before starting, don’t miss these considerations:

• How much storage do you need? If you depend on local storage, you won’t be flexible to grow and scale. You won’t be able to handle large workloads.
• Is your application event-driven? If it is, you should be able to process asynchronously because your application will be stretched across several machines.
• Flexible messaging is required. There will be multiple event sources and they all have to be processed. That’s why you need a robust messaging model.
• Creating an API communication schema will also be mandatory as microservices will be using their APIs to communicate.
• You’ll need a more secure model which will allow one microservice to access only the resources it needs, without exposing other microservices to security threats.

Microservices have made a serious revolution in software architecture. You should take them into serious consideration when it comes to building applications. Netflix, Amazon, Uber, and Spotify are only some of the tech giants that have decided to leverage the advantages of microservices for their large, complex applications.

However, migrating to microservices should depend on the project and the team structure. This will be a great deal for the entire company so you should discuss it seriously.

Previously published at https://microtica.com/everything-about-microservices/