<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=658098&amp;fmt=gif">

Microservices: not just a buzzword

7 min read

24-03-2020 17:05

For you to quickly get an idea of where we’re heading, here is the TL;DR version about microservices, some of its main benefits and why it’s a big thing:

  • Quickly scale and deliver new features and upgrades to market
  • Rapidly iterate to find your next business model
  • Improve and empower developer engagement

With this in mind, let’s take a step back and discuss a bit about monolithic apps, the counterpart to microservices.

Monolithic or packaged apps: why they’re getting old

The traditional way of building enterprise applications, using a monolithic approach, is becoming problematic as applications get larger and more complex or when your business needs to make adaptations to its product/service in order to respond to demand.

More and more developers are turning to microservices software development architectures, in which applications are structured as collections of loosely coupled services instead of taking the monolithic approach and writing (possibly) millions of lines of customised code on top of the original (monolithic) application.

The microservice mindset makes it easier to build, and much easier to expand and scale.

Think about it, let’s compare to how cars were made and how they are done nowadays. In the past, a single team was responsible for building a car from start to finish, consuming a lot of time. The employees were responsible for all tasks at once. Then, Ford pioneered the assembly line, by standardising car parts that could be assembled more easily, producing cars faster than ever before. A revolution to the automobile industry.

That’s the same thing for microservices. You have a specialised team for each service, operating independently.

 

Let’s take a closer look in this blog post to understand all about the topic.

What are Microservices (AKA Microservices Architectures)

Microservices are individual pieces of business functionalities that are independently developed, deployed and managed by a small team of people from different disciplines.

Here is a video that will help:


So, as you saw, microservices are a simplified approach to the modular application development. It’s also a way to modernize your legacy applications.

Many big and well-known companies, like Netflix, Amazon, Uber, Paypal, and eBay run on microservices. By taking this approach, is easier to build more complex and larger apps with a combination of small services.

On the other hand, in a monolithic architecture, all software components are interconnected and interdependent. If any component or single application fails, the complete app could go down. You don't want that, right?

 

Imagine that you’re an e-commerce and it’s Black Friday season. You have a web application including functions like payment, products, cart, history and log in. If the payment function consumes more memory, the entire application can be in danger, and you’re going to be in trouble…

For instance, in a microservices scenario, the service payment getting a lot of traffic wouldn’t be a problem, due to the scalability and flexibility of it.

Microservice-ify ALL THE THINGS!

By now you are probably wondering: “Oh, I have to move to this new incredible thing NOW!”

isolate services

Hold!

This step needs good planning first, that’s the most important part. Also, you might want to consider other things first:

  1. Are you in familiar territory?
  2. Is your team (or teams) prepared?
  3. How’s your Infrastructure?
  4. Evaluate the business risk!

Maybe you have a very simple app that not many people use and that you don’t have any plans to make it more powerful in the long run. Maybe microservices isn’t for you at the moment. And that’s ok!

Here are some scenarios that could indicate that you should start your next project using a monolithic architecture:

  1. 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.
  2. 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.
  3. 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.

However, here are some good news: Syone can help you there ;)

Let’s now dive into the nitty-gritty microservices, so take a deep breath!

Characteristics of Microservices


1 - Do one thing and do it well

A large monolithic application can have millions of lines of code and perform hundreds of individual business functions.

Microservices, on the other hand, each perform exactly one business function. Doing one thing well allow teams to stay focused and for the complexity to stay at a minimum. That’s the defining characteristic of microservices.

2 - Encapsulation

Each microservice should own its own datastore, cache store, storage volume, and so on. Interaction with the outside is through well-defined APIs.

Besides, this way each team can be more independent and operate without compromising other teams work.

3 - Autonomy and ownership

Each team is able to build and deploy its own microservice at any time for any reason, without having to coordinate with anyone else. Each team also has a lot of freedom in making its own decisions.

Benefits of using Microservices


Faster Time to Market

One of the main benefits of microservices is that you can improve speed and productivity by breaking down applications into smaller services which can be developed quickly.

Different teams can continue to work on various components without waiting for the others.

Important note: initially, it might take some time to start due to the complexity introduced by microservices. But after this first step, each team can independently innovate and release features quickly.

Isolated Components and Autonomous Teams

As we saw before, microservices architecture allows developers to build loosely coupled services to be developed, modified, and scaled individually.

Better and Less Complex Code

Microservices tends to produce much better code because a single microservice performs exactly one business function. This way, a small codebase tends to be better than a much larger one.

Mix of technologies

Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

Better Fault isolation

A failure in one microservice does not affect the functioning of other microservices in an application.

Better Scalling

By using microservices, it’s much easier to find slow bottlenecks. Each microservices can be scaled to resolve identified bottlenecks, offering a better overall user experience.

Security

Each microservice exposes a small granular bit of business functionality as an API. It’s easy to see exactly who or what is calling each API.

Rather than dealing with security at the application layer, you can instead use an API gateway or API load balancer. Calls from one API to another pass through the API gateway or API load balancer. Each request is evaluated against a ruleset to see if it can be passed to the endpoint.

Microservices and containers: a perfect match

Containers are an important part of most microservices deployments. First of all, they were born at about the same time, and they are extremely complementary.

Each microservice team can package up their microservices into one or more containers. This makes it easier for developers to run microservices locally and for individual microservices to rapidly scale up and down in real-time.

There are some tools you can use for containers and microservices, like Microsoft Azure Kubernetes Service (AKS) and Red Hat OpenShift.

You can also read more about containers here and here.

Microservices closure

The microservices mindset is a revolution to how the market is reacting to these new technologies and possibilities of making development easier and better for the future.

New features can be released in hours rather than months, although microservices are complex in the beginning. But after you go through the maturity level, the gain is exponential, specially if your application is sufficiently complex and you have the organisational maturity.

microservices kubernetes containers


So, if you want to know more about microservices, containers, Kubernetes, Azure, OpenShift or any other solution that can increase your performance, get in touch with us.

Hope you enjoyed the reading, cheers!

Red Hat Openshift datasheet

 

Vitor Calil Silva
Written by Vitor Calil Silva

Hands on professional, more than 10 years experience in digital marketing and a fan about how technology can improve our daily tasks.

Post a Comment

Featured

How to assure business continuity with the changes imposed by COVID-19
machine learning talk linas matkasse SYONE
Check out a case study video about the leading meal kit provider in the Nordics. Find out how they reduced costs and food waste with Machine Learning.