An introduction to Microservices

So what are Microservices? Wikipedia has a good definition: “Microservices are a software development technique - a variant of the service-oriented architecture (SOA) structural style - that arranges an application as a collection of loosely coupled services.”. They can also be thought of as a decomposition that provides a service which can be linked to other services or a set of services easily - almost like linking a series of home components in providing internet in home services.

Microservices represent an exciting opportunity for organisations to engage their communities with agility.  Each microservice can be deployed, upgraded, scaled and restarted independently and are typically orchestrated by an automated system, making it possible to make frequent updates without affecting the end users.  By enabling small autonomous teams to develop, deploy and scale their respective services independently, microservices essentially parallelize development — thereby speeding up the production cycle. The main benefit of a microservices architecture isn’t technical — it’s in team development and people management.

However, they can also be difficult to get right.  Taking to a legacy architecture with a microservices migration project requires chipping away at the right components.  Legacy systems of record that are well architected may not even be worth taking.  It is best to look for functions that differentiate your organisation with customers and communities you serve.  The best candidate systems or parts of a monolith for migration are those that require agility and can set you apart as you serve your customers or third party partners. 

It should be noted that while there are obvious benefits in a microservices approach, there are inherent risks and disruptions that will inevitably come when decoupling monolithic architectures.  It is often assumed a microservices approach will lead to management challenges and the organisation should be geared up to handle them as they arise.  The road to microservices will be one many organizations will decide not to follow.  These organizations have ultimately decided to optimize, as much as possible, the monolithic technology stacks that serve as core to the overall enterprise.

Organizations without the engineering resources or skill to knit together a stable infrastructure with existing open source code and tools have struggled to make the benefits of microservices outweigh the challenges.  However, many organizations have reached a point at which the pain of managing the monolith outweighs the pain of the organizational change required to adopt a new, microservices approach.

In this first discussion we will introduce containerisation and some of the other important technical considerations.

Containerisation and Orchestration

Although not necessary, the ‘deployment’ of microservices can be greatly enabled through a container based orchestration framework.  In the current cloud native world, containers and microservices almost go hand in hand.  Whereas, an SOA ran on virtual machines (VMs) that required time and investment to build, deploy and run, containers changed the game by virtualising the operating system.  Containers were first introduced through Docker in 2013.  Docker was an open source release of PaaS products that enabled software to be delivered in packages called containers.  This enabled the abstraction from the operating system and a more sophisticated type of packaging than the technical community had been using.  Container technologies could be built, run and managed with little overhead — a stark contrast to the heavyweight world of SOA, which required substantial investments, particularly in networking and storage.

The significant evolution of containers came with Kubernetes.  Docker was behind both the Open Container Initiative and Cloud Native Computing Foundation that led to Kubernetes.  Kubernetes effectively leveraged containers by creating a place for workloads to be managed across services and even platforms (or cloud providers).  

Kubernetes’ namesake is a Greek word, κυβερνήτης, meaning “helmsman” or “pilot.” This definitely encapsulates the meaning. More fully, a ZDNet article by Scott Fulton defines it as: “... a workload distribution and orchestration mechanism for clustered servers in a data center, ensuring resource availability, accessibility, and balanced execution for multiple services concurrently.” Furthermore, it facilitates orchestration or distributed data processing through the passing of state and exposes this process to observability and manageability.

In the same article, Fulton further contrasts orchestration to an operating system.  “In one respect, though, what an operating system is to a single computer, an orchestrator is to a cluster of servers: It oversees the execution of software in a system whose infrastructure resources -- its processing power, memory, storage, and networking facilities -- have all been merged.”  This is a great comparison and what makes it important for a multi-cloud world is that this portability can work across a variety of operating systems.

Other Orchestration options include Docker Swarm (that evolved in parallel with Kubernetes) and RedHat OpenShift which was re-architected to run on Kubernetes in 2015. Microsoft have also been working hard to tweak the Azure architecture to provide an orchestration offering the Azure Kubernetes Service. Apache Mesos has also been built through this period. A Microsoft collaboration then spawned Mesosphere DC/OS which still exists as an offering. AWS also introduced the Elastic Kubernetes Service (EKS) in 2018 (this being in addition to their more long running proprietary ECS service).

Microservices and Containers Relationship

Before going any further, we should discuss workload and service definitions.  When we introduced containers above, we talked of a packaging software.  This effectively can be considered a workload.  A workload could also be considered to be multiple packages but what is key is cohesion - it must singularly or in aggregate do one task or major task completely. 

Fulton’s take on a service definition is “...a service is software that, given specified inputs and pointed to relevant data, produces a predictable set of outputs”. This definition builds on the concept of cohesion but really sets up the architectural independence that is important for Microservices.

Most containerised components being orchestrated today are services or microservices.   In the context of a container, the microservice is an encapsulated interoperable unit that can be managed, deployed and orchestrated as architecture building blocks.

So containers and orchestration is an important part of microservices. Although you do not absolutely require containerisation (ie. you could run Microservices directly on EC2 instances and also even make them agnostic to a level), it really does help with the interoperability of this architecture.

The challenge with the orchestration is balancing the complexity of your orchestration platform and establishing the right patterns in the microservices to ensure at a detailed level they can be portable.  Kubernetes continues to improve functionality.  Simplifying this where possible is important (HashiCorp Nomad is positioned as a ‘simpler’ cluster management option to Kubernetes).  As you commence your microservices migration, a set of patterns to aid in robust development decisions would be valuable. 

APIs

Microservices are facilitated through an Application Programming Interface (API) that defines the specific role provided by the underlying service.  They are the key interface to the rest of the world. 

In microservices management, it is important to catalogue, curate and be in constant ‘discovery’.   The management function will play an important role in the decision around what microservices should be kept as part of the companies private catalogue and which should be made available to the public.  In building an ecosystem of partners (like banks with Fintech’s) this is an important organisational decision that could be a path for growth.  This will obviously also require the right level of security for this API and microservice(s) before public access is established.

As with any API, versioning is essential.  New features can be added, but old ones should rarely be subtracted. When a microservice is deployed for the first time, it immediately becomes a dependency somewhere else.

Often the most complex part of the application is not the actual services themselves, but the communication between those services.  By breaking monolithic applications into small microservices, the communication overhead increases because microservices have to talk to each other.  Service meshes are an additional layer for handling inter-service communication, which is responsible for monitoring and controlling traffic in microservice architectures.  This allows tasks, like service discovery, to be completely handled by this layer.

Other Technology Considerations

Security

There are 3 areas of security that require consideration for microservices.  First, as microservices leverage APIs for access, this can result in an environment being more susceptible to security attacks.  Second, the reach of orchestration tools into container runtime environments can make the architecture more vulnerable.  Lastly, the network centric integration and the sheer complexity and dynamism of a full microservices environment can also introduce challenges.

Organisations have begun to move security further into the development lifecycle so that security teams are more involved in engineering and vice versa to help fend off these vulnerabilities.  This is commonly termed DevSecOps.  With microservices, as they are further from the OS and memory aspects of earlier architectures, network security is more important.  Full stack engineers should consider security in their cloud native application or microservices development practices - particularly a low-trust, identity based security paradigm.

It should be noted that containers themselves can serve as an excellent security fence for the applications or microservices within.   To ensure that containers and their associated images do not propagate infections, they should also be designed to be small and with minimal privileges.  Short container lives also help reduce risks.  Additional areas to watch include the trust defined in the interaction with the source of the container usage and the type of access to the underlying operating system.  

A service mesh is an easy way to heighten the securing of microservices and containers.  A service mesh is a dedicated infrastructure layer that controls service-to-service communication over a network.  An example service mesh is Hashicorp Consul or recently released Redhat Openshift Service Mesh.

Further security considerations include the continual vetting of microservices code through DevOps, knowing how your orchestration functions from a security perspective, and the implications of abstracting from the operating system - negating some of the native OS security provisions.  Although a well developed ‘chain’ of microservices can shut out attacks earlier, traditional network security tools can fall short in adequate coverage of microservices due to their dynamic nature.

Container images are the key source of vulnerabilities.  Publicly shared images are frequently infected and thus unsafe for production environments.  Image scanning features of container registries make it easy to scan all container images downloaded.  They run checks for the known vulnerabilities and follow the CIS Docker Security Benchmark.

DevOps, Deployment and Operations

Before Microservices can be deployed, there is a reasonable amount of foundation work required.  Some of the infrastructure needed would include load balancers, monitoring and observability systems, orchestration, security model, message queues, container images etc.  In addition, the core DevOps chain toolset needs to be established.   If this is established, container or code/object deployment units that form the services can be managed.

What is true for legacy, cloud native applications and microservices is that data is not being systematically managed through the DevOps cycle and deployment.  Much of the data provision in test data management and related data is still treated manually.  The data challenge is heightened in microservices due to the treatment of state and the proliferation of outside datastores.  

Streaming services can help with the data persistence challenge.  A good DevOps function should also be able to facilitate snapshots and rollback.  Regardless, data management need to be considered and understood as you start using and deploying Microservices.

As there may be a woven set of microservices and logs to manage for both the development and operations role, a good telemetry or observability solution is needed. People have been focusing on just setting up microservices since their adoption began a few years back, but people are just starting to realize that complexity becomes an issue when managing hundreds or perhaps thousands of interdependent microservices. New Relic One is emerging as a solid option in this space and can span microservices.

For Devops though, you will still need to define a set of tools to support your architecture.  There is no silver bullet.  Tools including Draft,  Helm, Skaffold, Spinnaker and Telepresence.  These are relatively new and specifically for cloud native applications.  They operate with observability at the center and leverage codifying practices.  Another popular option is to use Prometheus.  Prometheus is an open-source monitoring and alerting toolkit that is often used in combination with Grafana to visualize the collected metrics.

While these technologies bring the benefits of scale and agility, they also introduce complexity when managing them at scale.  For example, the Kubernetes container orchestrator makes it easy for you to deploy an application that scales across a 1,000-node cluster and deals with deployment and node failures.  However, it can be complex to route traffic for that service, to monitor the overall health of the service — not just of individual nodes and pods — and to ensure fair resource allocation between this service and others

within the cluster.  New service mesh technologies, for example, when paired with Kubernetes, enable traffic management, service identity, policy enforcement and telemetry for microservices.

Summary

Microservices represent an exciting evolution in architecture. The evolution from SOA to Microservices has spawned many improvements, iterations and enabling technologies.  In this blog we have tried to cover a few of the technologies that we feel are important when you are considering your microservices framework.  The major one is how you will leverage containers and orchestration as an enabling platform to build multi-cloud enabled microservices.  The others really support DevOps through to deployment and the operations.  Last but not least is security and how you will manage this and build this into the fabric of your development cycle and the framework.  

Microservices is still relatively new with a fast evolving ecosystem of tools and patterns for implementation. But it is certain that the tools are built for people and teams familiar with DevOps practices. Microservices require organizations to rethink the existing software architecture that runs their business, and how the organization can adapt to practices that require new technical skills and a cultural shift to match. It’s daunting, risky and not for everyone.

The best approach for one organization may be the absolute wrong way for another.  By starting small, iterating and, above all, evaluating and adapting best practices and patterns for its own needs, an organization may make a successful transition to a microservices architecture that is performant, resilient and secure and allows teams to move and innovate faster.