In our nineteenth issue of the Architects' Newsletter we are once again 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" and predominantly moved into the late majority adoption phase. 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

Experiences Moving from Microservices to Workflows at Jet

On InfoQ, Jan Stenberg summarised a blog post by James Novino, an engineer at Jet who described the pain points of Jet's Order Management System (OMS) and the related migration to a new version of this application. The OMS is responsible for a number of business functions, and was originally developed using a collection of microservice-based orchestrating tasks. As the company grew, the maintenance and operational challenges with this architecture also grew until they ultimately decided to build a new workflow-based platform.

This article provides an overview of the new platform and summaries the experience from the Jet team after running this in production for just over a year. Migration from a distributed microservice architecture to one based on workflows has had a dramatic positive effect on the overhead of design, development and support within this use case.

O'Reilly Publishes State of Microservices Maturity Report

Microservices are evolving from fad to trend, according to an InfoQ summary of "The State of Microservices Maturity" survey, conducted by O'Reilly and Neal Ford in July 2018 and published in December. This is a conclusion that is aligned with InfoQ's own released recently Architecture and Design Trends Report.

The O'Reilly report showed an overall positive attitude towards microservices among the practitioners surveyed for the report. Among the most significant findings in the report is that DevOps and microservices feed off each other, so that the success of one contributes heavily to the success of the other.

Microservices After Two Years

In a recent blog post, George Stocker discussed his experience of working with complex microservice-based systems over the past two years. He argues that as much as microservices are currently in vogue, they are in reality simply another tool to help make software development better and to make systems easier to maintain. Microservices provide many benefits and have many trade-offs with traditional monoliths, and he suggested that it is rarely clear whether or not a system should be developed as a monolith or as microservices.

A key takeaway from the article is that there are typically several factors that can steer the choice towards one or the other architecture style, but those factors depend greatly on the "individuals, organizational leadership, business model, constraints, and politics of the organization implementing those services".

Developing Microservices with BDD and Interface Oriented Design

In a recent article, Ken Pugh discussed the benefits and practicalities of developing microservices with Behavior Driven Development (BDD) and Interface Oriented Design. Key takeaways from the article included: using BDD when building microservices can improve collaboration between the important "triad" of consumer developers, producer developers, and testers; creating well-defined contracts for microservice interfaces using Interface Oriented Design provides a good long-term return on investment; and it is vital to create tests that check failures are appropriately handled.

Kubernetes Service Catalog: Overview and Current Limitations

In a recent InfoQ article, Ara Pulido discussed the use of the Kubernetes-focused "Service Catalog", a declarative Kubernetes API extension to discover and use managed cloud services. Service Catalog lets you provision cloud services directly from the "comfort of native Kubernetes tooling". This project is currently in incubation with the goals of bringing integration with service brokers to the Kubernetes ecosystem via the Open Service Broker API.

A core conclusion from Pulido is that although Azure, AWS and GCP have Service Broker implementations for their public-cloud based services, the Service Catalog needs to overcome several current limitations before it can become widely adopted and safely used in production.

Case Study

Rewriting a Microservices API Gateway Service from Clojure to Go: AppsFlyer Experience Report

AppsFlyer a leading mobile attribution and marketing analytics platform, processes nearly 70+ billion HTTP requests a day (approximately 50 million requests a minute), and is built using a microservices architecture style. The entry point to the system that wraps all of the frontend services is a mission-critical (non-micro) service called the API Gateway. This essentially serves as a single point for routing traffic from customers to all backend services, simplifying authentication and authorization exponentially for clients, but with the tradeoff of also potentially being a single point of failure.

Originally, AppsFlyer's services were a Python monolith, which required a single solution for authentication and authorization that was created as part of the monolith itself. As time went by the traffic and complexity grew, and the team migrated to a microservice architecture, predominantly written in Clojure. The AppsFlyer team have talked previously about how technical debt originates, and this happened within their API Gateway service. This led to the decision to completely rebuild the gateway service from first principles, including exploring the use of other languages.

The AppsFlyer team understood that to be able to properly evaluate suitability of different languages they would need to examine several aspects; most importantly performance, as well as specific benefits of each language for the specific task at hand. To measure performance they understood they would need to properly benchmark Clojure versus Go within an as production-like simulation as possible. To do so, they started by undertaking simulations and stress testing using NGINX (enhanced by Lua) as one option, alongside Golang and Clojure prototype implementations. Go delivered improved throughput versus Clojure.

On top of these results, and from a syntax perspective, Go also provided the added benefit of being a typed language that was easier to update and reiterate on, and can be easily extended using the existing packages and libraries. From the perspective of functionality, Go's built-in support for a reverse proxy component at its core was also an important benefit for writing an API gateway.

After building and testing the final implementation of a new API gateway in Go, the most critical results for the team came from a performance and throughput perspective, which enabled an improved user-experience for their clients. Simulations show that the newly deployed solution is also capable of supporting exponentially more traffic than it does today.

The full length article, "Rewriting an API Gateway Service from Clojure to Golang: AppsFlyer Experience Report" can be found on InfoQ.

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:

Practical AI and ML Conference QCon.ai (April 15-17, 2019) announces keynote!

Francois Chollet, software engineer at Google & Creator of Keras discusses best practices for deep learning in the opening keynote for QCon.ai conference. The talk covers techniques and recommendations for designing highly productive APIs for ML and offers essential updates on the new TensorFlow 2.0 framework. Register for the conference using the code infoqai19 to get an $80 discount!

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.