Adopting cloud-native development increases:
- speed of software development and deployment
- productivity of teams doing systems development, systems support and IT operations, and
- ability to use leading-edge, cloud-native third-party services
These benefits can transform organizations and their clients. New and/or significantly improved products and services are a common outcome, as is a move to continuous improvement of products and services. This means that the business case for cloud ranges from reduced infrastructure costs to increased commercial success. Given these results, you would be crazy not to take this step but adopting cloud-native development often requires a change of culture — it is more than using new processes and technologies. This article describes the ethos and elements of cloud-native development; barriers to and benefits of adoption; and how cloud-native development relates to cloud-native applications and services, especially those from major cloud providers.
Cloud-native development is an approach to building and running applications that exploits the advantages of the cloud computing delivery model. The Cloud Native Computing Foundation (CNFC) talks about using “… an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization. Cloud native technologies enable software developers to build great products faster.” (CNCF, 2019). It is that last part that should cause executives to sit up and take notice. The ability to add new features on a daily basis and to launch new products and services in timeframes previously thought impossible can be the difference between being an upper quartile company and being stuck in the pack. This is why cloud-native is the development method of choice for Facebook, Amazon, Netflix, Google and other software-driven, technology-centric, cloud-based organizations.
Cloud-native development achieves its magic by linking and automating the work of systems development, systems support and IT operations teams. The speed of pushing new software to production increases dramatically, while quality improves as opportunities for error are removed from previously manual processes.
The four tenets of cloud-native development are: (1) micro-services; (2) containers; (3) continuous delivery; and, (4) DevOps. Each is discussed below:
1. Microservices in this context means building applications as collections of small, independent services that communicate over HTTP APIs. It allows autonomous teams to work in parallel on the same application, and results in code that is not tied to infrastructure instances; faster creation of new applications, products and services; and, applications that are easier to understand, develop, test and support.
2. Containerization is virtualization at the operating system level, as compared to the virtualization of hardware from ‘traditional’ Virtual Machines (VMs). It allows single servers to be divided dynamically into one or more isolated containers. By doing so, it provides improved efficiency in infrastructure utilization and speed of deployment compared with traditional VMs; an ideal compute vehicle for deploying and scaling individual microservices (such as low overhead for creating and destroying containers); the ability to manage and migrate application dependencies with the application; and the ability to abstract the operating system and the Cloud platform away from the application. It is achieved, using tools such as Docker, by separating the internal elements of the application instance from external elements such as host OS, libraries (and other binaries), and configuration files. Containerization allows development teams to focus on building business functionality without having to worry about server memory, provisioning, and other performance and resource restrictions — which results in significant improvements in speed and productivity.
3. Continuous delivery allows software to be generated frequently, reliably and ready to be deployed to production. It is achieved by automation, specifically continuous integration (automated build and test), and automated delivery processes. Continuous delivery results in development work being normalized and standardized for IT Operations; code always in a deployable state; the option of automated, continuous deployment; and faster feedback from customers. Faster, more reliable delivery and improved build quality are just two of many benefits.
4. DevOps is an approach to increasing speed and quality of software development, delivery and deployment that centers around increased collaboration between developers and IT operations personnel. The aim is achieved by linking and automating the processes of software delivery and making related infrastructure changes. DevOps results in shorter software delivery times; more responsive organizations; and quality assured from idea to design, build, deployment, daily use and support. You can do DevOps within traditional on-prem infrastructures, but it is much easier when cloud is providing a standard, centralized platform for automated testing, deployment, and production that is not available with the distributed systems model.
As well as the four tenets of cloud-native development described above, good practice also includes agile methods; wide scope; open culture; welcoming change; immutable infrastructure; container orchestration; service meshes; and loose coupling.
Agile. Agile methods are hugely compatible with the continuous change philosophy of cloud-native development. Teams building, deploying, running and managing applications through automated toolchains are part of this. Build automation, deployment automation, testing automation, static code analysis automation, and scaling automation together result in significantly increased speed of development and deployment, as well as increased productivity and responsiveness. They also improve quality by reducing the potential for human error.
Scope. There is always an outside world and other services with which systems need to communicate. This means integrating with cloud-services beyond your own containers and virtual machines for things like email notifications; setting up databases; managing DNS records; retrieving log files/metrics from applications; sending warnings and alerts, etc. At a more transformative level, cloud gives development teams access to so much more than they could ever build themselves. For example, the Google Transfer service can copy hundreds of GBs of data per second from S3 (Amazon’s Simple Storage Service). Google BigQuery is arguably the fastest technology ever for interactive analysis of massively large datasets. Networking in AWS is so fast that it is quicker to query data over the network than to read it from disk. Google TPUs act as AI accelerators while Cloud Spanner is a database service built specifically for cloud that combines the benefits of relational databases with the horizontal scalability of non-relational databases. Finally, Amazon SageMaker is a fully-managed comprehensive service providing algorithms for developers to create machine learning solutions. Meanwhile, systems development, DevOps and IT operations teams can use Serverless Computing’ models where responsibility for server processes and hardware is outsourced to BaaS (‘back-end as a service’) and FaaS (‘functions as a Service’) providers. They can also take advantage of ‘disposable infrastructure’ services such as pre-emptible VM’s that are provided to them cheaply by cloud providers, to utilize spare capacity at the provider (but can be taken back with almost no notice when non-discounted demand returns). The scope and power of what is available to development, DevOps and IT operations teams from cloud providers is growing by the day — and the increased scope means opportunities for vastly increased speed and depth of data analysis; use of AI; and speed of development and deployment.
It could be argued that many of the revolutionary cloud-based services described above are available to development teams regardless of whether they use cloud-native development practices or not. In theory, teams practicing waterfall development methods in document-heavy bureaucracies can still use leading edge technologies, but in reality it does not happen. A development team wedded to traditional approaches will not be adopting leading edge technologies. Instead, they will keep using the technologies they know. This leads us to…
Culture. An open culture welcoming of change across all areas involved in designing, developing and delivering services to customers is essential if cloud-native is to be adopted and used to the full extent. Examples of welcoming change include losing attachments to old ways of working such as slow processes for approvals, tests and packaging. You are not doing cloud-native development if you are scheduling software drops into production once every two weeks, and if there is a significant period of time (and work) between creating working software and it going into production. It simply does not work that way. Cloud-native is about achieving continuous integration, continuous delivery and even continuous (ie automated) deployment. If a change requires dual approval, a formal sign-off, a week-long test cycle and another week to prepare production packages, then that organization is practicing traditional on-prem development in a cloud environment. Failing to understand and accept that fact is not a technical issue, it is a cultural issue. This is a common problem — in fact ‘on-prem dev in cloud’ is more common than ‘cloud-native in cloud’ and is the main reason why so many organizations fail to achieve anything close to the full benefits of cloud.
Immutable infrastructure means never modifying servers once they are deployed, because modifying live servers always results in a certain percentage being broken in the process (the cause of many service outages in many industries). If changes are required, then new servers should be built from a common image instead of amending a previous build. Modifying servers is traditional IT and is best left in the past.
Container orchestration. The rise of lightweight, flexible containers has created new application architectures that have fundamentally changed how applications are deployed and visualized. The containerization approach is to package the different services that constitute an application into separate compute containers, and to deploy those containers across a cluster of physical or virtual machines. This has driven the need for efficient ways of defining, provisioning, scheduling and managing containers at scale. Tools such as Kubernetes and Mesos fulfil that need.
Service meshes are dedicated infrastructure layers for making service-to-service communication safe, fast, and reliable. If you are building a cloud-native application, you need a service mesh. Tools such as Istio or Linkerd provide a configurable infrastructure layer that makes communication between service instances flexible, reliable, and fast. They provide traffic management, security, monitoring and observability; support for a ‘circuit breaker pattern’ that isolates unhealthy instances; and, other capabilities essential for modern software architectures.
Loose coupling means developers breaking tasks down into separate services that can run on several servers in different locations, and not tying code to infrastructure instances. Because the infrastructure that supports a cloud-native app does not run locally, cloud-native applications must be planned with redundancy in mind so the application can withstand equipment failure and be able to re-map IP addresses automatically. This part of cloud design is massively cost-effective because services and resources for computation and storage can be scaled out horizontally as needed, which negates the need for overprovisioning hardware and having to plan for load balancing (virtual servers can always be added quickly).
Now that the components and best-practice for cloud-native have been described, can there be any doubt about its adoption? You might think not, but it happens, and the causal factors are people and culture not technology. Typically, the problem is a lack of prior experience in cloud computing generally or cloud-native development in particular. It may not be active resistance to cloud-native that is the problem, but instead people simply not knowing what they don’t know. No one can blame them for that. If no one in a development team has ever used cloud-native, then it is unrealistic to expect them to do so without a lot of help. It is down to the people leading the move to cloud infrastructure to include cloud-native development, cloud-native applications and third-party cloud services in the scope of migration. These things do not look after themselves. Those in positions of COO / CIO / CTO need to understand and be able to explain the nature and importance of cloud-native development and cloud-native applications and services to their colleagues. They will also need to act as coaches once the transition is underway. Some of the approaches and technologies of cloud-native involve a genuine paradigm-shift for people and organizations. This means that change management in general, and culture change in particular must be in the skill set of those leading the transition.
Unfortunately, but perhaps inevitably in certain circumstances, significant changes in personnel are sometimes needed in successful moves to the cloud. The ‘circumstances’ being in cases where the need for an injection of skills, knowledge and experience in cloud has been overlooked in the planning process. For example, the executive board of one important, highly-regarded financial institution instigated a move to cloud to satisfy strong requirements for systems modernization and improved security. Unfortunately, the move proved to be problematic and disappointing. Lack of previous cloud experience in the company was identified by the executive board as the main causal factor, so they initiated a 50% replacement of IT personnel (including the leader) with all new hires being required to have significant expertise and experience in cloud infrastructure and cloud-native development. Cloud subsequently became a significant success for the organization. Obviously, it would have been better if the firm had anticipated and addressed the skills and experience gap in advance so as to minimize the need for staff turnover, but the conclusion remains that getting people onboard who are experienced in cloud is critical to the endeavour. Do not go into cloud-native without hiring experts in the field.
Fast-forward to when your migration challenges have been overcome; your IT teams are doing real cloud-native development and, they are using leading edge cloud-native services to help transform the experience of your customers. How do you know that the transition has been successful? To have an objective picture, it is best to have continuous metrics, an automated way to collect data, and a defined way to make decisions based on those data. Comparing the outcome against the original business case is important as doing so will force you to scrutinize which parts of the transition still needs to be addressed. The full scope of the business case for cloud is large and complex and it is often the case that opportunities and issues are overlooked. Benefits realization always needs to be an active process — and data is essential to make it happen.
In summary, the benefits of adopting cloud-native development are:
• Speed: faster time to market for new features, products and services
• Productivity: more software released more often by same sized teams
• Efficiency: automated infrastructure management for the application layer
• Reliability: safer and easier to handle rapid releases, replace failed components and recover from unexpected events
• Culture: increased collaboration between software development and IT operations teams
• Scope: easy access to a range of third-party services that is transforming technology-based services in every aspect of our lives
• Commercial: switches cloud from being a cost-saving decision to a driver of organizational success.
Adopting cloud-native development, applications and services is essential if you are to realize the full benefits of cloud infrastructure. It can swing initially more on people and culture than on processes and technologies, but having a clear view of the processes, technologies and services that will be enabled by the move is important because it is those things that will transform the experience of your customers and the success of your company. Cloud is so much more than a cheaper way to operate IT infrastructure. Instead, it is the path to increased organisational success. Cloud-native is a critical part of achieving that success. Good luck with your own endeavors — it will be worth it!
By Cliff Moyce,
Chairman of Advisory Board, Finance Practice at DataArt.
