So, what are Microservices?

Part 1: You may have heard the term Microservices before, but every time you do, you ask yourself -- What exactly is a microservice?

Let’s break down exactly what this technology is, why it’s so great for organizations to leverage and challenges they should prepare for.

The origin of Microservices

Microservices are a concept that comes out of service-oriented architecture (SOA). It’s a software development technique in which an application or service offering is a collection of loosely coupled independent services that are designed to do one thing very well but only one thing. Microservices tend to be self-contained pieces of functionality focusing on completing one thing. These are normally used in collections of many Microservices, often referred to as a pattern or a Microservices architecture.

The idea here is that there is a significant amount of service granularity that can be completed by utilizing Microservices. Or, to say it differently, using Microservices, a large application id divvied up into many smaller building blocks, each an executable piece of software that as a whole collection (also known as a pattern), offers the full functionality of a single monolithic application. Each of those small components can then be managed by a small team, with very clear and clean boundaries around what their team is managing.  

Now that we’ve gone over the concept behind Microservices, we need real-world examples. One of the common examples of Microservices is all the containerized application parts sitting within a container, in a docker environment being managed by a workflow system. Another example would be utilizing third-party drop-in components for building out a large and complex transactional system, which needs to utilize a large number of small services, each with reusable integrations and APIs for each component to talk to each other, one of a number of APIs that often purport to connect anything

Often these components are broken into three categories: system, process, and experience. System components are going to be focused on managing your core components of the service you’re offering. Processes are going to be your workflows and what gives you that flexibility to connect to different components. This is also going to be the experience or UI of what the product actually looks like.

Now that we know what a Microservice is, let’s get down to business. 

Why do I want a Microservices architecture? 

In general, Microservices are considered to be very agile tools often focusing on resilience, minimization of service size and complexity, elasticity as well as standardization.

The number one advantage of utilizing Microservices is simply their agility to deploy, update, and develop components without rebuilding the entire service or application. So you may be asking yourself, how do these benefits work, and come to be?

There are four distinct categories: modularity, scalability, integration and distributed development.

• Modularity allows application developers to truly understand develop components, which is less likely to take down the entire application with a minor change. We’ve all heard about one change breaking everything - this is a fundamental concept that we are trying to get rid of when dealing with Microservices.
• Scalability is the idea that each piece is independent, so they can be deployed quickly and easily. This allows for monitoring of individual components and to quickly scaleup deployments to deal with specific workloads.
• Integration is possible because all the components are separate, each component is dealing with a specific task. This allows for quicker implementation in an integration with older legacy systems. This is done in order to take a monolithic application and deploy pieces to slowly supplant some of the architecture that’s in that monolithic application. This is something very hard to do without utilizing Microservices.
• Distributed Development allows dozens of small teams, usually around six to nine developers, to go in and modify each component to understand the input and the output standards, as well as their independent goals, this is done in order to truly develop their components at rapid speed. With a Microservice architecture, the development process can be streamlined and completed quickly, this adds value because testing on an individual service, and a full regression testing are not required.

Without question the capability of the Microservices-centric design can dramatically speed up development and deployment. Individual components can be updated as the teams develop and test, without updating the entirety of the entire service or application framework or service.

Are there any concerns a company could face with a Microservices architecture?

Microservices might sound awesome now, but when you get a full architecture built utilizing Microservices in either service-oriented architecture (SOA) or Microservices architecture (MSA), you are referring to massive collections of Microservices, which can lead to serious issues.

Concern #1 -- Do too many people have access to my Microservices?

The first issue that comes to mind is the lack of privacy in the design. Can that exist when potentially dozens of different teams or vendors are each working in a single component of the full application or service, independently?

When thinking about security, you have to be able to create walls around what a product can or cannot do. Identifying vulnerabilities is second nature to a lot of programmers today. However, if there are thousands of Microservices in a single solution, there can be a few problems when it comes to applying security.

Security can be difficult when There are too many teams that have access to data flowing between the different Microservices, as well as too many teams that are identifying their individual security requirements. Microservices almost always fall into the agile project management concept, however, if there are dozens or even hundreds of product owners, aligning your security requirements can be a complex problem.

Concern #2 -- Do you know where these Microservices are from?

The second main concern with Microservices is if a component was developed in-house or a purchase service.

When utilizing purchased Microservices, layering them together into a pattern, when there is an issue or question is not as simple as saying, will this work? It’s going to require testing.

Additionally, some of the privacy impacts may be unknown. Remember, most Microservices are designed for simple point-to-point passing of information. This leaves questions about security and privacy. And if a third-party Microservice is being used, it’s important to ensure they meet compliance and privacy requirements.

Concern #3 -- What third-parties have access to my Microservices?

The last major concern when you talk about security first is simply that in many cases, teams are often managing too many security entitlements (e.g. file access, provisioning controls, etc.). With Microservices, you have many different people, managing many different disparate collections of entitlements and processes. Some of these tend to be developed and even managed by outside vendors.

In the end, you can always pass off work to outside vendors. You can always pass off tasks to outside vendors. However, you can never pass off liability to outside vendors for things such as compliance legal requirements or public perception of your company.

Concern #4 -- Do I really need Microservices?

When dealing with Microservices, remember your entire development methodology is going in that direction.  At the core of today's development is the idea of continuous deployment or continuous delivery.  This is the heart of DevOps, the methodology used today that is a combination of practices that combines software development (Dev) and information-technology operations (Ops).  This shortens the systems development life cycle dramatically and provide continuous delivery with high software quality using… generally, Microservices.

Closing thoughts...

So while Microservices can be a great advantage for your company to utilize in quickly updating, developing and integrating different services and applications throughout their enterprise or in public-facing environments, is it always the right choice? Is there really even a choice?

High-security concern areas such as privacy and identity, are areas where Microservices have to be very carefully thought out. In general, the question has to be asked, is this the right technology to be managing personal data?  What boundaries need to be put around high security areas?

Photo credit: Panchenko Vladimir/ Shutterstock

Robert Meyers is Compliance and Privacy Professional, at One Identity.