Cloud Journey — Part 5

What is Platform Ops?

My Learnings

  • Platform ops is the team that delivers, maintains and improves a platform as a service (PaaS), including the continuous integration/continuous delivery (CI/CD) toolchain, for multiple agile application teams delivering custom-built software.
  • The goal of platform ops is to achieve efficiencies and economies of scale in a DevSecOps environment, where application product delivery teams are responsible for deploying and operating their own applications. A shared consistent platform reduces duplication of technology, enables automation and focuses expertise.
  • The platform is itself a product used by developers. Collaboration between platform ops and development teams is essential to create a software-defined platform that operates to the standard required to protect the organization while allowing the development teams to move fast.
  • The platform ops approach is effective whether the underlying infrastructure is in a public cloud, a private cloud, or a virtualized and automated environment on-premises. The details are different, but the high-level functions are common, including security, access control, compliance, cost management and performance management.
  • Treat your platform as a product. The developers using it are your customers, and their requirements should define the platform and your priorities. Your goal is to enable your internal customers (development teams) to deliver services to your organization’s customers.
  • Collaborate with application delivery teams to establish a cross-functional team, platform and operating model that meet business needs. Pushing a platform on application developers has a high risk of failure in capability and adoption.
  • Build teams, processes and culture that will continually improve — not just sustain — the platform through collaboration with platform users. The technologies you deliver to meet developer and platform needs will change and, thus, shouldn’t overshadow the nontechnical aspects of the initiative. Treat evangelism, support and training for your internal customers as seriously as a commercial platform provider would for its paying customers.
  • Use an agile approach by targeting an “anchor” application team and delivering a platform to meet their needs first. Often, this will mean taking over operational responsibility for a platform that the anchor team members were running themselves. Their success will create more demand and diverse requirements.
  • Built on-premises from multiple components (such as open-source Kubernetes or a virtual machine environment highly automated with Red Hat Ansible)
  • Based on commercial platform products (such as Red Hat OpenShift or VMware Tanzu)
  • Composed with governance from public cloud services (such as AWS Elastic Beanstalk or Azure Kubernetes Service)
  • The inner architecture, which describes the software architecture of an individual microservice and what it exposes to the outside world.
  • The outer architecture, which describes the operating environment, platform and distributed management ecosystem in which your microservices will be built, deployed, executed and supported.
  • All product teams will benefit from a reliable CD pipeline, regardless of their deployment requirements, whether they are using containers, aPaaS or more traditional software packaging.
  • It will improve product teams’ ability to work in small batches and incorporate customer feedback along the way.
  • It greatly lowers the risk of errors during the release process and creates a level of predictability not found in manual deployments.
  • “How to Architect Continuous Delivery Pipelines for Cloud-Native Applications” discusses how today’s businesses demand rapid software delivery to stay ahead of the competition, adopt new business models and move into new markets.

Meet Demand for Rapid, Continuous Delivery With a Fluid Release Schedule

  • Train service: The release schedule of traditional development approaches and architectures can be likened to a railroad schedule. The planning and delivery of different pieces of functionality are linked and delivered in specific, scheduled time intervals, much like regularly scheduled trains. This approach provides benefits in efficiency and dependency validation, but it constrains the speed and cadence of functional delivery. Passengers on a train cannot depart until the scheduled time. Similarly, any application functionality in a traditional architecture approach must wait to be delivered in a scheduled release — or wait for other pieces it depends on to be completed — before it can reach the users who need it. Agile Release Trains in the Scaled Agile Framework (SAFe) are an example of this model.
  • Taxi service: Microservices, by contrast, are more akin to a taxi-dispatching service. Taxi passengers depart as soon as they’re ready to go — rather than on a scheduled departure time. Likewise, microservices can be used to deliver smaller chunks of functionality fluidly, quickly and dynamically. Because pieces of new functionality don’t have to wait on a deployment schedule, users don’t have to wait as long to take advantage of new functionality. Of course, independently changing the components of your system means you have the additional complexity of managing dependencies. Managing dependences requires disciplined interface design and versioning. It also requires late binding between services at invocation time using service discovery and request routing.
  • Each multi-experience app, API and multi-grained service should be independently built, tested and deployed.
  • APIs connecting apps to back-end services (outer APIs) should be mediated to promote consistency, simplify management and provide abstraction.
  • APIs should apply a consumer-centric design principle, where the developers/applications using those APIs are the consumers.
  • A domain-driven design should be used to identify strong boundaries, and to establish integration and composition requirements between those domains.
  • Domain interfaces should be designed to enable the consumption, composition and integration necessary to meet the flexibility goals of the solution, using the most appropriate API styles.
  • For each component of the architecture, ownership for implementation, versioning and operations must be established.
  • Adoption of MASA is gradual. Organizations must start small, make the necessary adjustments and evolve the architecture over time. MASA is never “done.”
  • Microservices architecture — Use MSA when you are creating applications that demand a fast pace of change. Ensure that the increased cost of operation is justified by the ability to deliver business-driven changes quickly, and that the demand for change will remain over time. Do not use MSA for applications with a slow pace of change.
  • Event-driven architecture — Use EDA when you need to decouple data providers from consumers, and when you need to enable multiple consumers of a single stream of events. Do not use EDA for cases where the sender needs to know whether a message has been received.
  • Mesh app and service architecture — Use MASA when you need to create multiple user experiences from shared services. Do not use it for cases where a single N-tiered application will suffice.
  • Headless/API-centric architecture — Use headless architecture when you need to decouple user interfaces from back-end services in order to modify existing capabilities or integrate new capabilities. Do not use it when operational simplicity is a higher priority than agility and flexibility.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store