DEV Community

Cover image for Everything You Need to Know to Get Started with Microservices
Sara Miteva for Microtica

Posted on • Updated on

Everything You Need to Know to Get Started with 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:


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.


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.

Scalability in microservices

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.


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.


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.


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 challenges, 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 and Microservices

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.

Top comments (18)

phlash profile image
Phil Ashby

Nice introduction to some of the technologies and terminology Sara!

I always find myself returning to James Lewis & Martin Fowler's article on microservices to refresh my understanding of why and how this architectural style can or indeed should be applied, as sometimes it should not!

I would also caution against joining a technology cargo cult based on 'because Netflix, or Soundcloud do it this way', primarily because we are not (and are unlikely to ever be) Netflix. Our challenges are different and need to be understood properly, using local knowledge from the business and the technology teams, before embarking on major structural shift - as you put it: This will be a great deal for the entire company so you should discuss it seriously.

If readers have time (40 hours of videos!), I highly recommend this on line course from Udi Dahan on distributed system design, which is currently free (normally several thousand $$): to cover the wider aspects.

That said - my business are part way through a transition towards microservices, and while we are not getting it completely right (hey, it's new, we're human), it's been very refreshing to experiment with new ways or working, decentralizing design authority / autonomy and modern cloud native technology. In our case a primary driver was decoupling the large team into smaller more autonomous squads (yes, we are trying out that stuff too!) with fewer barriers to deployment and more robust operational processes to be able to move faster in our market. Technology and process/methodology choices were taken based on this need, not because they looked cool on a CV :)

saramiteva profile image
Sara Miteva

I completely agree with you Phil.

Usually, there are a lot of variations of microservice architecture out there. Teams are trying to create something that they think will be the most suitable solution for them. A few years ago, when we were starting with microservices we tended to create a microservice for each entity in the system and one microservice which was doing all the business logic and orchestration of other services. Quickly that service became sort of a monolith.

We realized that this is a bad design so after that we took a step back and started developing microservices that will solve certain domain problems like Continuous Integration, User management, etc. Now we have fewer microservices but still are able to organize our teams in multiple squads and spend very little time on maintenance on our infrastructure.

I guess the crucial thing is to find the right time and the extent to which embrace the microservice architecture.

Thank you for the additional resources :)

cheetah100 profile image
Peter Harrison

If you are bulding independent functionality with broadly different capabilities then deploying these capabilities as separate services makes sense. That is you need to organise Microservices based on what they do.

There is a danger that they can become based around objects in the domain. Each Microservice should have it's own resources such as databases. The idea is that they don't share common databases. To create separate services around individual domain objects will only make things less scalable.

My own approach has been a general purpose platform which is runtime configurable, much like a database server can have a runtime defined schema. We have made the platform application totally configurable from data objects to user interface. I've extended this all the way to the REST interfaces. This way any node in the cluster can service any call.

No worries about scaling up, just add more nodes to the cluster. Because any node services any call there are no service choke points. Because configuration is runtime there are no deployments. Business rules are adaptable, not burnt into the binary.

The same technology runs equally well on a single box and a distributed cluster. It also means that rather than huge IT teams you could start giving managers ownership and control over their own processes and applications.

saramiteva profile image
Sara Miteva

Interesting approach Peter, sounds catchy.

What would be the boundaries of the problem this kind of platform would solve? Is it everything you could imagine, or the focus will still be in certain areas like software delivery automation, IoT, finances etc.?

In my opinion, a general-purpose platform would give more flexibility but at the same time it would require strict knowledge and expertise to define and represent the problem to be solved.

If you consider a SaaS that abstracts a great amount of complexity with delivering web applications or microservices on Kubernetes, for somebody to be able to do the same in a general-purpose platform would require a lot of time and expertise to make it work.

Usually, there are cases when somebody likes more flexibility and cases where somebody likes to focus primarily on building the business and leave other aspects to be solved by competent SaaS.

cheetah100 profile image
Peter Harrison

The situation with this project is complicated. It is not an offering you can buy or something you can find in a public open source repo, at least not yet.
We don't yet have a system capable of creating fully rich business applications. There are some missing components to be considered a full application development platform, but it is being used to deliver multiple analytics applications. The trajectory is toward a business application development environment.
My experience so far is that you need designers with a good understanding of data and UI design. These designers don't need to know how to code, but they do need to know about databases, data transformations, how to set up visualizations and navigation. Once configured it has a elegant UI for the users.
Basically there are three tiers. There are the developers who maintain the core platform infrastructure. Then there are designers who configure applications who are not coders but who are skilled with the tool. Then there are users who simply use the finished applications.
I'm not keen to claim this a totally generic 'application development' system because I'm fully aware of the folly of such claims. It aims at business systems which work with textual data and business processes communicating with other systems and partners.
I know this might sound 'too good to be true', but it is founded on some hard won experience and good ideas from many people over several years. Hopefully one day I will be able to show everyone.

phlash profile image
Phil Ashby

This sounds like the 'scaled monolith' pattern, with the code/logic to handle any events available but not always used (configuration applies constraints) across a compute platform? The challenge (as expressed by @sarafian ) is in disciplined deployment and operational expertise, promoting configuration and config management (CMDB) to a first class citizen of the ecosystem (as it should be!).

Udi Dahan (course linked from my earlier comment), and others suggest that SOA (and by extension microservices) allow focused solutions to business problems to be created directly in custom code, rather than attempting to predict the future and develop a configuration-driven 'toolbox of capabilities' that makes others (typically consultants - see SAP!) responsible for understanding and solving business problems. I guess it depends what you are selling - the toolbox or the business outcomes ;)

sarafian profile image
Alex Sarafian

Thank you Phil (@phlash909 ). I personally find this aspect the most under considered in any topic in IT and only Fowler is one of the few people actually discussing it as part of the "solution". And the most funny thing is that these questions are primarily for the business people (set the business goals) and they refuse to engage and just consider it a technical "solution". But no solution exists to an undefined problem and therefore undefined expectations.

sarafian profile image
Alex Sarafian

Exhaustive article and will done for the effort. Not sure what the purpose was. The only one I see is to do some sort of indexing of what is available. Don't get me wrong, it helps a lot.

Anyhow as a high level topic missed is how to make the services speak with each other. Synchronous or asynchronous probably with RPC.

Another topic is the versioning and the rollout. In my opinion if this is not understood or the culture can't deal with it, then microservices are wrong.

Too extend the above, the single most important topic to discuss is culture compatibility and not only with the development team. From what are the goals to what to expect and governance and more. Essentially how the entire organisation operates.

With regards to data, this is something almost never discussed. Most people consider a microservice as a reusable instance for every domain. But it shouldn't be like that. I group my services around one domain and those micro-services become internals along with their databases, which means copying databases. Kind of depends on the purpose.

saramiteva profile image
Sara Miteva

I agree, these are very important topics. But, they are very wide and deserve separate articles written for them. We could elaborate on them in some of our next articles.

sarafian profile image
Alex Sarafian

Yes but so did the others you mentioned. I'm not criticizing you, just pointing gaps in what I think was an exercise post that resulted in some indexing of resources on the topic. Well done btw

shulugh profile image
Sesugh Hulugh

I have read a number of articles on microservices and this has been by far the most simply explained. Would like to have an idea of what domain model designs would be like in this scenario. Eg I have a microservice that manages warehouses and inventory, then another that manages purchasing of goods that will be stored in these warehouses, will I have to replicate the domain model and database table for warehouses in both applications? Because if the purchasing microservice pulls its warehouse list form an API coming from the warehouse service, then purchasing can never happen if the warehouse microservice has an issue

saramiteva profile image
Sara Miteva

This is a topic that is discussed a lot with many different opinions involved.

In general, sharing a database between microservices is not a best practice because you can quickly lose control over who is doing what with the database. Database update of one microservice could potentially corrupt other microservice and you will end up with a broken system.

Another thing to consider is that microservices should do more than CRUD operations, otherwise you should consider merging multiple services that solve one domain problem in one. So if you need
data for inventory I guess there would be additional logic that you wouldn’t like to duplicate in the purchasing microservice.

When applying domain-driven development, the domain is the holy grail. You group system functionalities based on domain problems they are solving. Reliable communication between microservices is something that should be solved with different strategies like a circuit breaker, events, queues, error handling, etc.

phantas0s profile image
Matthieu Cneude

Micro-services are nice. Monoliths can be nice, too. Now, I think the real challenge is to decompose your problem domain in order to have independent modules, micro-service or not.

An architecture style won't do that for you. Only your brain (or the collective brain of the team).

lyas777 profile image

Muy buena explicación, gracias :D

saramiteva profile image
Sara Miteva

Gracias a ti también :D

alikham profile image
Ali Khan

Thank you, this is very informative and brilliantly written!

saramiteva profile image
Sara Miteva

Thank you so much Ali :)

techtter profile image

Will gRPC replaces REST?
gRPC: Is it replaces RESTful webservices?

If you want to know what is gRPC and how to implement Microservices using gRPC framework, then check out following playlist:
gRPC Java Tutorial: