In our eighteenth issue of the Architects' Newsletter we are focusing on the topic of microservices. In the year since we last looked at the topic, it really has become mainstream, and we consider it as having "crossed the chasm" into early majority status. Inevitably, as more and more teams are adopting this style of architecture, each organisation brings its own culture and perspective on the technology adoption curve. Understanding all the emerging microservice patterns, antipatterns, and technologies is therefore essential for a software architect.

News

Exploring Azure Service Fabric Mesh: A Platform for Building Mission Critical Microservices

Azure Service Fabric Mesh (currently in preview) is a fully managed service that allows engineers to build, deploy and manage applications consisting of polyglot services running within containers using a "serverless" approach. InfoQ recently sat down with Chacko Daniel, Principal Technical PM at Microsoft and service owner of the Azure Service Fabric Cluster service and Azure Service Fabric Mesh service, and discussed how this offering relates to existing Platform as a Service (PaaS) and Container-infrastructure as a Service (CIaaS) solutions like Cloud Foundry and Kubernetes.

Azure Service Fabric Mesh has a strong focus on being an application platform, first by abstracting the container/process orchestration away from the end-engineer, and also by adding intelligent messaging routing and storage that you can use with your applications. The platform service provides intelligent message routing through software defined networking (SDN) capabilities, built using the pervasive Envoy Proxy, which enable service discovery and routing between microservices.

AWS Releases "Firecracker", an Open Source Rust-Based microVM for Container and Serverless Workloads

At the AWS re:Invent 2018 conference Amazon announced the release of Firecracker, an open source virtualization technology that is purpose-built for "creating and managing secure, multi-tenant containers and functions-based services". Firecracker is a fork of Chromium OS's Virtual Machine Monitor (crosvm), an open source VMM written in Rust, and the technology is used behind the scenes to power the organisation's microservice and FaaS deployment runtimes: Amazon's AWS Fargate and AWS Lambda services.

What We Got Wrong: Lessons from the Birth of Microservices at Google

At QCon San Francisco, Ben Sigelman, CEO of LightStep and ex-Googler, suggested that although Google deserves a lot of credit for popularising what we now call "microservice architectures", several mistakes were made as the engineering team learned how best to implement this pattern. Many of the mistakes that were made at Google are being recreated by the rest of the industry today.

This talk explores key lessons, such as:

• Ensure that you know why you want to adopt microservices, and understand the associated benefits and constraints
• Understand that "serverless still runs on servers", and engineers need to develop mechanical sympathy for the compute fabric they are deploying onto
• "independence is not an absolute" - all systems have some degree of coupling, and this must be recognised from both a technical and organisational perspective
• Although implementing observability within a microservice system is essential, beware of "giant monitoring dashboards". Instead, focus on the detection of critical signals, and refining the search space
• "You can't trace everything (or can you?)" Here Sigelman presented a guide on how to use distributed tracing effectively.

Micronaut Tutorial: Part 2: Easy Distributed Tracing, JWT Security and AWS Lambda Deployment

In the first article within this series, Sergio del Amo Caballero developed and deployed three microservices with the JVM-based Micronaut microservices framework. This second InfoQ tutorial article explores and adds several features to the sample application, focused on security, tracing, and serverless deployment.

Several security solutions are provided "out-of-the-box" with the framework, such as JWT-based authentications, and Micronaut provides features such as "Token Propagation" to ease secure communication between microservices. Micronaut provides seamless integration with several distributed tracing solutions, such as Zipkin and Jaeger. Finally, thanks to its low memory footprint, Micronaut is capable of running in Function as a Service (FaaS) serverless environments.

How to Make Linux Microservice-Aware with Cilium and eBPF

In this QCon San Francisco video, Thomas Graf, co-founder and CTO of Isovalent, discusses "How to Make Linux Microservice-Aware with Cilium and eBPF". Topics covered include: the evolution of applications running, from a single process to microservices; problems of the Linux kernel; an introduction to Berkeley Packet Filter (BFP) Linux kernel technology; and the use of BPF with the Cilium service mesh.

Microservices: The More the Merrier or Meshy-er?

In a Container Journal article, Lee Calcote, Head of Technology Strategy at SolarWinds, argued that "successful deployment of microservices or adoption of a container architecture does not happen overnight", and instead the majority of teams are responsible for existing/legacy infrastructure and services. Accordingly, the journey to becoming "cloud native" is likely to be iterative.

Calcote discussed that microservices have benefits and challenges for which "service meshes may be the best tool to address [them]". His primary advice is: when considering whether to deploy a service mesh or not, first gauge the necessity. If this technology appears to be a good fit, then your use case must be considered before choosing a deployment model. For example, will the mesh be running on a container or VM-based infrastructure. Calcote maintains the "Layer 5 Service Mesh Landscape", that contains a list of current mesh implementations.

Case Study

Using Golang to Build Microservices at The Economist: A Retrospective

Kathryn Jonas joined The Economist engineering team with the job title of Drupal Developer. However, the real task was to engage in a project that would fundamentally reshape the technology delivering Economist content. The first few months were spent learning Go, working with an external consultant to build a technology-exploration MVP, and then rejoining the team to guide them on their journey to Go. This shift in technology was driven by The Economist's mission to reach a broader digital audience as news consumption moved away from print.

The Economist needed more flexibility to deliver content to increasingly diverse digital channels. To achieve this goal of flexibility and maintain a high level of performance and reliability, the platform transitioned from a monolith to microservice architecture. Services being written in Go was a key component of the new system that would enable The Economist to deliver scalable, high performing services and quickly iterate new products.

Implementing Go at The Economist had the following impact:

• Allowed engineers to quickly iterate and develop new features
• Enforced best practices on fast-failing services with smart error handling
• Provided robust support for concurrency and networking in a distributed system
• Lacked some maturity and support in some areas required for content and media
• Facilitated a platform that could perform at scale for digital publishing

Overall, Jonas believed the project had a positive impact, and Go is one of the critical elements that has allowed the content platform to scale. Go will not always be the right tool, and that's fine. The Economist has a polyglot platform and uses different languages where it makes sense. Go is likely never going to be a top choice when messing around with text blobs and dynamic content, so Javascript is still in the toolset. However, Go's strengths are the backbone that allows the system to scale and evolve.

When considering if Go would be the right fit for your microservices project, review the key questions for system design:

• What are your system goals?
• What guarantees are you providing your consumers?
• What architecture and patterns are right for your system?
• How will your system need to scale?

If you're designing a system that aims to tackle the challenges of distributed data, asynchronous workflows, and high performance and scaling, Jonas recommends considering Go and exploring how it can accelerate your system goals.

The full-length version of this article can be found on InfoQ: "Using Golang to Build Microservices at The Economist: A Retrospective".

To get notifications when InfoQ publishes content on this topic follow Microservices on InfoQ.

Missed a newsletter? You can find all of the previous issues on InfoQ.

This edition of The Software Architects' Newsletter is brought to you by:

Lyft's Move to Microservices: A Case Study

To rapidly scale its system and support growth, Lyft started to explore moving from a monolithic architecture to microservices. Today, Lyft deploys more than 200 microservices in its distributed architecture, and this number is growing. These services work together to perform fundamental functions of the Lyft app; however, it’s a challenge to quickly and accurately monitor Lyft’s system as the number of microservices grows.

To pinpoint the root cause of a performance issue, developers must understand every service that is invoked and the performance of each of those services. To gain insight into this level of performance as efficiently as possible, Lyft chose to implement [x]PM and Envoy, the service mesh technology.

InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.