Deploying Reactive Microservices

Chapter 1. Introduction

Every business out there now is a software company, is a digital company.

Satya Nadella, Ignite 2015

This report is about deploying Reactive microservices and is the final installment in this Reactive microservices series. Jonas Bonér introduces us to Reactive and why the Reactive principles so inherently apply to microservices in Reactive Microservices Architecture. Markus Eisele’s Developing Reactive Microservices explores the implementation of Reactive microservices using the Lagom Framework. You’re encouraged to review those works prior to reading this publication. I will presume basic familiarity with Reactive and the Reactive Manifesto.

Thus far in the series, you have seen how adherence to the core Reactive traits is critical to building services that are decoupled but integrated, isolated but composable, extensible and maintainable, all while being resilient and scalable in production. Your deployment systems are no different. All applications are now distributed systems, and distributed applications need to be deployed to systems that are equally designed for and capable of distributed operation. At the same time, the deployment pipeline and cluster can inadvertently lock applications into container-specific solutions or services. An application that is tightly coupled with its deployment requires more effort to be migrated to another deployment system and thus is more vulnerable to difficulties with the selected provider.

This report aims to demonstrate that not only should you be certain to utilize the Reactive patterns in our operational platforms as well as your applications, but in doing so, you can enable teams to deliver software with precision and confidence. It is critical that these tools be dependable, but it is equally important that they also be enjoyable to work with in order to enable adoption by both developers and operations. The deployment toolset must be a reliable engine, for it is at the heart of iterative software delivery.

This report deploys the Chirper Lagom sample application using the Lightbend Enterprise Suite. The Lightbend Enterprise Suite provides advanced, out-of-the-box tools to help you build, manage, and monitor microservices. These tools are themselves Reactive applications. They were designed and developed using the very Reactive traits and principles examined in this series. Collectively, this series describes how organizations design, build, deploy, and manage software at scale in the data-fueled race of today’s marketplace with agility and confidence using Reactive microservices.

Every Company Is a Software Company

Change is at the heart of the drive to adopt microservices. Big data is no longer at rest. It is now fast data streams. Enterprises are evolving to use fast data streams in order to mitigate the risk of being disrupted by small, faster fish. They are becoming software service providers. They are using software and data for everything from enhancing user experiences to obtaining levels of efficiency that were previously unimaginable. Markets are changing as a result. Companies today increasingly view themselves as having become software companies with expertise in their traditional sectors.

In response, enterprises are adopting what you would recognize as modern development practices across the organization. They are embracing Agile and DevOps style practices. The classical centralized infrastructure solutions are no longer sufficient. At the same time, organizations now outsource their hardware needs nearly as readily as electrical power generation simply because it is more efficient in most every case. Organizations are restructuring into results-oriented teams. Product delivery teams are being tasked with the responsibility for the overall success of services. These forces are at the core of the rise of DevOps practices and the adoption of deployment platforms such as Lightbend Enterprise Suite, Kubernetes, Mesosphere DC/OS, IBM OpenWhisk, and Amazon Web Services’ Lambda within enterprises today.

Operations departments within organizations are increasingly becoming a resource provider that provisions and monitors computing resources and services of various forms. Their focus is shifting to the security, reliability, resilience, and efficient use of the resources consumed by the organization. Those resources themselves are configured by software and delivered as services using very little or no human effort.

Having been tasked to satisfy many diverse needs and concerns, operation departments realize that they must modernize, but are understandably hesitant to commit to an early leader. Consider the serverless, event-driven, Function as a Service platforms that are gaining popularity for their simplicity. Like the batch schedulers before them, many of these systems will prove too limited for system and service use cases which require a richer set of interfaces for managing long-running components and state. Operations teams must also consider the amount of vendor lock-in introduced in the vendor-specific formats and processes. Should the organizations not yet fully trust cloud services, they may require an on-premise container management solution. Building one’s own solution, however, has another version of lock-in: owning that solution. These conflicting interests alone can make finding a suitable system challenging for any organization.

At the same time, developers are increasingly becoming responsible for the overall success of applications in deployment. “It works for us” is no longer an acceptable response to problem reports. Development teams need to design, develop, and test in an environment similar to production from the beginning. Multi-instance testing in a clustered environment is not a task prior to shipping, it is how services are built and tested. Testing with three or more instances must be performed during development, as that approach is much more likely to detect problems in distributed systems than testing only with single instances.

Once confronted with the operational tooling generally available, developers are frustrated and dismayed. Integration is often cumbersome on the development process. Developers don’t want to spend a lot of time setting up and running test environments. If something is too difficult to test and that test is not automated, the reality is too often that it just won’t be properly tested. Technical leads know that composable interfaces are key for productivity, and that concurrency, latency, and scalability can cripple applications when sound architectural principles are not adhered to. Development and operations teams are demanding more from the operational machinery on which they depend for the success of their applications and services.

Microservices are one of the most interesting beneficiaries of the Reactive principles in recent years. Reactive deployment systems leverage those principles to meet today’s challenges of cloud computing, mobile devices, and Internet of Things (IoT).

Full-Stack Reactive

Reactive microservices must be deployed to a Reactive service orchestration layer in order to be highly available. The Reactive principles, as defined by the Reactive Manifesto, are the very foundation of this Reactive microservices series. In Reactive Microservices Architecture, Jonas explains why principles such as acting autonomously, Asynchronous Message-Passing, and patterns like shared nothing architecture are requirements for computing today. Without the decoupling these provide, it is impossible to reach the level of compartmentalization and containment needed for isolation and resilience.

Just as a high-rise tower depends upon its foundation for stability, Reactive microservices must be deployed to a Reactive deployment system so that organizations building these microservices can get the most out of them. You would seriously question the architect who suggests building your new high-rise tower on an existing foundation, as is. It may have been fine for the smaller structure, but it is unlikely to be able to meet the weight, electrical, water, and safety requirements of the new, taller structure. Likewise, you want to use the best, purpose-built foundation when deploying your Reactive microservices.

This report walks through the deployment of a sample Reactive microservices-based application using the Developer Sandbox from Lightbend Enterprise Suite, Lightbend’s offering for organizations building, managing, and monitoring Reactive microservices. The example application is built using Lagom, a framework that helps Java and Scala developers easily follow the described requirements for building distributed, Reactive systems.

Deploy with Confidence

A deployment platform must be developer and operator friendly in order to enable the highly productive, iterative development being sought by enterprises undergoing software-led transformations. Development teams are increasingly realizing that their Reactive applications should be deployed to an equally Reactive deployment platform. This increases the overall resilience of the deployment while providing first-class support for peer clustering applications such as Actor systems. With the complexity of managing state in a distributed deployment being handled Reactively, the deployment workflow becomes a simplified and reliable pipeline. This frees developers to address business needs instead of the many details of delivering clustered services.

The next chapter examines the importance of the Reactive traits in building a microservices delivery solution. We’ll look at key usability features to look for in a Reactive deployment system. In Chapter 3 you will test an implementation of these characteristics applied in practice by deploying the Chirper Lagom sample application using Lightbend Enterprise Suite. We’ll explore the resilience of the system by inducing failures and watching as the system responds and self-heals. I will then close out this Reactive microservices series and allow you to continue enjoying the thrill of a fully Reactive microservices stack deployment!