We are delighted to be able to share our second monthly architects' newsletter with you, which we will send on the last Friday of every month. 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.

If you do not want to receive it in future, unsubscribe.

News

Service Meshes: The Missing Piece of the Platform Puzzle?

September saw the Envoy service mesh proxy, written in C++ by Matt Klein and the team at Lyft, join the Cloud Native Computing Foundation (CNCF). This, alongside the existing linkerd JVM-based service mesh from Buoyant, now makes two service mesh-based projects hosted at the CNCF. The concept of a "service mesh" has risen in popularity recently, as it allows developers to implement loosely coupled microservices-based applications with an underlying mesh (or communication bus) to manage traffic flows between services, enforce access policies, and aggregate telemetry data.

Matt Klein, having previously worked on networking projects at AWS and Twitter, discussed the motivations for creating Envoy in a recent Medium post: "If Lyft was to realize the complete benefits of a fully distributed architecture it was imperative that we directly tackle microservice networking and observability". Service-to-service communication libraries like Finagle and the Netflix OSS suite are very powerful, but the library-based deployment approach was problematic at Twitter even though nearly 100% of services ran on the JVM; an update to Finagle might take months to fully rollout as service owners slowly upgraded and deployed.

At Lyft, Klein and the team wanted to replicate and expand on the feature set of Finagle, but move the functionality into a self-contained process that was easier to iterate and deploy. After investigating existing open source options and determining there was no good fit, Envoy was born. For performance reasons, modern C++ was chosen as the implementation language and development began in May 2015. By the early summer of 2016, Envoy was fully deployed at Lyft and being used for all edge and service to service networking, forming a mesh between over a hundred services and transiting millions of requests per second.

September also saw the release of Linkerd version 1.2.0, with new features and fixes targeting users running Linkerd with Kubernetes, HTTP/2 or gRPC. There are also several breaking changes with this release, and a migration guide has been created by the team at Buoyant.

NGINX have also jumped on to the service mesh bandwagon, with the release of a preview version of "nginmesh", an NGINX running as a sidecar proxy within the Istio service mesh data plane and framework. The release of nginmesh was part of a wider-ranging announcement from NGINX at their annual nginx.conf conference, including the new NGINX Application Platform which aims to be a "one stop shop" for providing the essential platform functionality for microservice developers and operators.

At the EMIT serverless conference, held in San Francisco, Shawn Burke also shared details of Uber's service mesh: Catalyst. Burke, a Staff Engineer at Uber, discussed the motivations to build a "serverless" service mesh using cloud agnostic technologies: it should be developer focused, and run in a similar manner on a local development machine as it does in production; it should dramatically simplify the process of delivering business logic; it must unify disparate systems with common patterns; and it must be fast (< 5ms P99). Catalyst is written in Go, and is currently undergoing production hardening. Although there is no timeline yet, Uber plans to open source Catalyst in the near future.

Are you ready for microservices? This eBook provides advice from 10 SecDevOps leaders on how to bake security into DevOps practices rather than treating it as an afterthought. Learn how your organization can benefit. Sponsored content

Resilient Functional Service Design

At CraftConf 2017 Uwe Friedrichsen discussed the core concepts of "Resilient Functional Service Design". Key takeaways included: microservice developers should learn about fault tolerant design patterns and caching, but not utilise them to mitigate fundamentally bad (overly-coupled) system design; understanding Domain-Driven Design (DDD) and modularity is vital; and aim for replaceability of components rather than reuse.

Friedrichsen, CTO at codecentric, began the presentation by stating that the goal of software development is to deliver business value, and for this to be realised the software must be run in production and be (highly) available. Modern architectural styles, such as microservices, mean that everything is now distributed (most likely spanning at least a local area network), and therefore failures within the system are normal and not predictable.

Developers should familiarise themselves with fault tolerant design patterns, such as circuit breakers, bulkheads, timeouts and retries, which have been popularised by Michael Nygard's "Release It!" book (of which a second version is currently available in beta). Caching, although useful, should be deployed with care, and not used simply to overcome bad system design, such as a long activation path involving many dependent services. The communication paradigm used within a microservices system also greatly influences the functional service design, and Friedrichsen suggested that care should be taken with upfront architectural choices that may limit future modification and extensibility.

Perspective on Architectural Fitness of Microservices

Philippe Assouline examined the potential architectural fitness of microservices in the context of Master Data Management (MDM), and the challenges a microservices-based architecture may face when solving problem domains that require compute-intensive tasks, such as the calculation of expected losses on a portfolio of unsecured consumer credit. Key takeaways from the article include: microservices are not a panacea; understanding the business domain is vital for assessing whether a microservices-based architecture is an adequate choice; the Single Responsibility Principle is key for delineating the functional boundary of microservices; like any other architectural style, microservices are governed by a set of tenets, and so it is important to understand how any deviation from these affects a given technology solution; and finally, microservices must be considered within the broader contexts of distributed architecture and distributed computing.

Apache OpenWebBeans Releases Meecrowave Server Version 1.0 for Java EE-based Microservices

Apache OpenWebBeans, an implementation of JSR 365 dependency injection (CDI 2.0), recently released version 1.0 of their Meecrowave microservices server that provides built-in support for the Java Persistence API (JPA), the Java Transaction API (JTA), and OAuth2 without requiring a full container such as Java EE. Meecrowave is built on top of existing Apache projects, including Tomcat (servlets), OpenWebBeans (CDI), Johnzon (JSON-P and JSON-B), and CFX (JAX-RS). A sample application can be found on GitHub.

Case Studies

Removing Friction in the Developer Experience: Adrian Trenaman Shares Experience from HBC at QCon NY

At QCon New York 2017 Adrian Trenaman presented "Removing Friction in the Developer Experience" in the new "Developer Experience: Level up Your Engineering Effectiveness" track. To mitigate the fear of development teams "breaking all the things" when deploying, the HBC team found implementing applications as microservices provided some level of isolation, and can prevent cascade failures when designed correctly. Trenaman also recommended the use of serverless technologies, and discussed how HBC has begun replacing parts of the architecture with implementations using AWS Lambda combined with Amazon API Gateway and AWS Key Management (KMS) service for handling user traffic ingress and authorisation/authentication respectively.

Key takeaways from the talk included: minimise the distance between "hello, world" and production; code is the primary artifact; seek out and remove friction in your engineering process; and give freedom-of-choice and freedom-of-movement to your engineers.

Monoliths to Microservices: A Virtual Event October 12, 2017 at 11 am EDT Learn how to deliver better apps faster with containers, DevOps, and microservices. Register today. Sponsored content

Distributed Schedulers with Microservice Architectures

Martin Campbell, microservices scalability expert at DigitalOcean, talked about running a microservice-based architecture with a distributed scheduler at MicroXchg Berlin 2017. He focused primarily on the problems encountered along the way, and the tradeoffs between offerings like Kubernetes, Nomad, and Mesos. Key takeaways included: distributed schedulers allow you to reason about a cluster as if it is a single physical machine; they make DevOps easier, reducing a lot of operational complexity that is particularly prevalent in microservice-based architectures; none of the offerings out there run stateful services particularly well, so it is best to not run these types of services using one; and in the event of a network partition, a fault tolerant distributed scheduler should leave all processes running even if their host nodes cannot talk to the master.

To keep up-to-date with everything InfoQ is publishing, you can follow the topics of Microservices and Service Meshes on InfoQ.

This is the second issue of a monthly newsletter, focusing exclusively on software architecture. We thought it would be valuable for you to get a quick overview of things you might like to keep an eye on. If this is not the case, you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.