Cloud Journey — Part 5

Cloud Journey Series:

We are leading a great transformational projects that is already live and have hundreds of thousands customer on it, you can read more about this transformation value streams in “ Transformation at Techcombank” which I explained in details about our DevSecOps practices. In this post, I will share more about using Platform Ops to accelerate DevSecOps adoption.

The platform ops team is responsible for providing a self-service development, deployment and operational platform that enables multiple software delivery teams to build and operate their own products.

What is Platform Ops?

Platform ops is an approach to scaling DevSecOps that involves dedicating a team to the delivery of a shared self-service app platform. Technical professionals focused on DevSecOps should use a product mindset to establish a platform that helps agile development teams deliver higher quality faster. DevSecOps is a customer-value-driven approach for delivering solutions that uses agile methods, collaboration and automation to meet shared goals.

You might ask, “Why do we need yet another form of ‘Ops’? We have NetOps, SecOps, DevSecOps, and even FinOps!” But in fact Platform Ops is actually different from the other “Ops” and increasingly serves as the glue that holds together all the different organizations and use cases required to meet the needs of technology organizations building modern, distributed, and cloud‑native applications. Platform ops leaders and team members must be able to code, configure and deploy apps, plus all the other things that engineers do. They advise and collaborate, but they can also dive into the trenches to get stuff done. This is also, by the way, how they learn what it really feels like to use the platform they have built for the dev teams.

My Learnings

After we have successfully launched all transformational projects (retail omni-channel banking, business omni-channel banking, DevSecOps, private cloud and others, you can read more on “ Transformation at Techcombank”), I have learned few key lessons that might worth sharing regarding Platform Ops:

  • 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.

Platform ops teams will not always create or build a shared platform on-premises. The responsibility of platform ops is to deliver and operate a platform, whether it is:

  • Built on-premises from multiple components (such as open-source Kubernetes or a virtual machine environment highly automated with Red Hat Ansible)

To apply product thinking to platform requirements gathering, start with customer goals, from developer and administrator personas, in specific scenarios, leading to a set of requirements. It is important to recruit willing, motivated and collaborative teams members with valuable technical skills for the formation of this team. Simply assigning your best, or available, resources to the team will undermine the culture from the start.

In a DevSecOps organization, you will relocate I&O professionals from traditional I&O silos into product development teams, supporting automation teams, cloud ops teams or SRE-style teams that sit alongside the platform ops team you are creating. These possibilities are shown in above figure. “ Analyzing the Role and Skills of the I&O Professional in DevOps “ provides context on this organization and skills transformation for I&O professionals.

Deployed and operational microservice applications encompass two architectural viewpoints:

  • The inner architecture, which describes the software architecture of an individual microservice and what it exposes to the outside world.

Following figure shows a microservice infrastructure, including the relationship between these two architecture views and the key components of the outer architecture as well as Platform Ops.

Continuous delivery (CD) has emerged as the preferred architecture for modern, agile software development, and organizations using agile methodologies should adopt continuous delivery without reservation. Platform ops should prioritize delivering a rock-solid continuous application delivery pipeline because:

  • 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.

Following figure shows the full pipeline and combines continuous integration with continuous delivery and deployment. Continuous delivery of software extends CI to include the automated build, test and non-production deployment of the application, followed by subsequent delivery to an operations or deployment function for production deployment.

Though a platform does not have to be based on containers or Kubernetes, those options offer a good example of the separation of concerns achievable in the platform ops model. The platform ops team is responsible for the care and feeding of the platform as a whole, and the product team creates and operates an application end to end by itself. Below figure summarizes the relative operations responsibilities for both the product team consuming the platform and the platform ops team. The role of platform ops is to enable the application teams to concentrate on delivering their application and forget about Kubernetes’ intricate infrastructure details. The model works when each type of operations team can do its work independently, occasionally collaborating on the deployment manifests (that is, files that define the relationship between the containers and the infrastructure).

Robust continuous delivery solutions require developing agile fluency and maturity, refactoring application architecture, and automating infrastructure to achieve a suitable delivery cadence. Continuous delivery (CD) makes it possible to regularly adapt software to incorporate user feedback, shifts in the market and changes to business strategy. Building a CD culture requires technical professionals to enhance development skills; change processes, practices and architecture; and automate everything. Engineering discipline is required to facilitate the complete automation of the delivery pipeline from the point where developers commit their code to the actual release to the user. Adoption of agile isn’t enough to enable CD. Agile teams are able to speed the development process, but without DevOps, they are not able to deliver any faster. This Solution Path provides guidance for technical professionals seeking to implement continuous delivery.

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

Organizations need a better understanding of how MicroService Architecture fulfills new business demands for rapid, continuous change. I am proud to announce we have achieved this in Techcombank as well.

They also need a firmer grasp of the complexity trade-offs involved in achieving these benefits. This understanding can be gained by considering the analogy of a “train service” versus a “taxi service,” as shown in Figure 5:

  • 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.

Adopting MicroService Architecture means embracing new team structures to match the new responsibilities and processes needed to deliver the new architecture. If your IT leaders are supportive of MicroService Architecture, they must also understand, support and help to implement this change in focus for you and your peers. Below figure shows the difference between organizational structures suitable for traditional application delivery (on the left) and teams organized to deliver microservices (on the right).

Mesh app and service architecture, shown in below figure, allows you to optimize for agility through modularity at all levels of a system. It promotes clear definitions of the components involved, the data and functional requirements of those components, and the optimal communication channel requirements between components. Mesh App & Service Architecture (MASA) enables the composable business.

The following are some key principles that Mesh App & Service Architecture (MASA) prescribes in building such an architecture:

  • Each multi-experience app, API and multi-grained service should be independently built, tested and deployed.

The key “hot” application architecture patterns that we see continuing to dominate architecture discussions and planning are:

  • 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.



Scaling Up, Growth and Digital Transformation guy.

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