At QCon San Francisco, Rafael Schloming presented "Service Oriented Development", and argued that an organisation migrating to microservices must seek to break up their monolithic development processes in addition to attempting to break up the system architecture. Treating newly formed microservice teams as internal "spinoffs" provides boundaries and encourages self-sufficiency and autonomy, and these teams must be supported by effective tooling for debugging, deploying and observing services within production.
Schloming, CTO and chief architect at Datawire, began the talk by asking the audience what their first questions would be when beginning a migration from a monolith to microservices based application. Common responses included: "how do I break up my monolith?", "how do I architect my app with microservices?" and "what infrastructure do I need in place before I can benefit from microservices?". Drawing on his experience with developing a microservices application at Datawire in 2013, Schloming argued that one of the most important questions -- although often ignored -- to ask is "how do I break up my monolithic process?", as the development process is critical to establishing and maintaining velocity.
When developing an application or service, the overarching delivery lifecycle can be divided into three phases: prototyping, production, and mission critical. It is often much easier to maintain high velocity of feature delivery in the prototyping stage, because stability is less important. As delivery moves from production to mission critical, velocity is often sacrificed for increased stability. Using a single delivery process for all components within an application is inefficient, as this forces a single stability vs velocity tradeoff.
Developing an application as a microservices-based system allows multiple processes to be used: each microservice/product team is free to choose the appropriate process according to their current stage within the delivery lifecycle. Microservices may be a distributed development architecture, but they are also allow a distributed development workflow consisting of many different simultaneous development processes with varying velocity/stability tradeoffs. However, moving to this way of working requires both organisation and technical changes.
From an organisational perspective, the creation of self-sufficient and autonomous software teams focused around a product is highly beneficial. However, this change from monolithic process to micro-processes requires education, communication and delegation. Everyone within a microservice product team will be exposed to the full development lifecycle -- from coding locally to deploying code to production via a continuous delivery pipeline and observing the application -- and this typically requires additional education. Ultimately, this change means that specialists have the opportunity to become generalists, which leads to the implementation of better holistic systems and operations.
People may not speak the same language across product teams, but this conflict can become a source of collaboration if harnessed correctly. Small teams within the organisation may own big important parts of the overall system, but this autonomy is the only way to effectively scale within a fast-paced market environment. Teams should strive to ensure that they do not need to rely on other teams to achieve their goal, and this includes eliminating reliance on a centralised architecture and operations team (although a "platform team" that provides self-service access to infrastructure is often beneficial).
Schloming argued that the best way to conceptualise the organisational change required to implement microservices is to think of each product team as a business spinoff. In much the same way as existing development teams may consume third-party services such as Twilio or Stripe, product teams should integrate with internal services using the same approach.
In regards to the technical implementation of microservices, Schloming outlined the goals of each delivery lifecycle stage: prototype - fast feedback from both tools and users; production users and growth - add features and do not disrupt users; and missional critical - ensure stability. This typically results in the operation of a single platform with parallel (microservice-based) workflows that can be transitioned as products mature. Practical examples of the technical challenges of each stage in the life cycle were presented using Docker, Kubernetes and the Envoy service proxy as the underlying platform components.
During the prototyping stage it can be challenging to get organisational buy-in for experimentation within production (for example, via A/B tests or canarying), and it is technically challenging to run microservices locally. A strategy to overcome this is to provide self-service provisioning and development containers that can be deployed to a remote environment via a continuous delivery pipeline. Schloming provided examples using open source tools the Datawire team has created, forge.sh -- for creating a portable development environment that is the single source of truth for build and dependencies -- and telepresence for proxying into a remote Kubernetes cluster -- allowing an application being developed locally (and associated debug tooling) to interact with the remote services as if it were running in the cluster.
For the production users and growth phase of the delivery lifecycle, the core challenges are measuring user impact of experimentation (and recognising the associated trade-off between velocity and stability), and testing new features and mitigating the impact of software bugs. Using multiversion deployment can overcome these issues, by allowing the canarying of new features (deployed as new services) and gradually increasing traffic as confidence increases in the metrics being observed. Envoy, a layer 7 (application) proxy built and run at scale by Matt Klein and the Lyft engineering team, can provide this functionality, as all traffic can be routed and controlled through this proxy. There has been increasing interest around this concept over the past six months with emergence of Istio (which uses Envoy as the service mesh data plane) and other "service meshes".
The challenges of the final phase -- mission critical software -- revolve around preventing regression of functionality and application observability. The strategy to overcome this consists of defining Service Level Objectives (SLOs) and implementing layer 7 observability. The creation of SLOs, and enforcement via contractual Service Level Agreements (SLAs), in an organisation-wide effort. The layer 7 observability can be implemented via Envoy (or a proxy equivalent to this), as this proxy operates at this layer of the networking stack, and has access to all service-to-service traffic within the network.
Schloming summarised his talk by stating that when an organisation begins a microservices migration, attention should be paid in regards to breaking up the monolithic process in addition to (and in priority of) breaking up the monolithic architecture. Organising microservice product teams as self-sufficient and autonomous "spinoffs" is beneficial, and tooling must be created in order to enable effective service-oriented development.
The slides for Rafael Schloming's "Service Oriented Development" (PDF, 2MB) talk can be found on the QCon SF website. The video of this and all the talks will be made available via InfoQ over the coming months.