8 steps towards cloud-native development

JAXenter: Thanks for taking the time to answer some of our questions. I’ll jump right in if that’s OK. In these times of Agile and DevOps, everything software development-related is getting faster and faster. The trend seems to be towards cloud-native application development. Could you briefly summarize what this means?

Cesar: Cloud-native application development is an approach to building and running applications that takes advantage of the cloud computing model based upon four key tenets:

• A service-based architecture (miniservices, microservices, SOA services, etc.)
• An API-driven approach for inter-service communication
• An underlying infrastructure that’s based on containers, and
• DevOps processes

The architecture and communication concerns are related to the development of cloud-native applications, and the infrastructure and process concerns are related to their delivery/deployment.

JAXenter: Right – but as always when changing mindset or approach, understanding what the move could mean is not necessarily the same as doing it successfully. Simply having the tools does not make the transition a success. What other considerations are there to be made when making such a profound shift?

Cesar: First, I’d recommend analyzing whether it makes sense for your project/application to go cloud-native. In many cases, due to government regulations or data compliance rules, many organizations cannot migrate their workloads to a cloud provider. But just because you’re not allowed to use a cloud provider doesn’t mean that you cannot take advantage of the cloud-native development approach. You just need to run your cloud on-premise.

Also, running your monoliths on the cloud doesn’t make them cloud-native. However, running your monoliths on the cloud using the DevOps and infrastructure tenets of cloud-native application development allows them to be included in the CI/CD pipelines and prepare them for a potential componentization into microservices, both of which can accelerate the delivery and deployment of your applications.

SEE ALSO: Java retrospective – best tools, frameworks and features of 2019

In summary, consider the best ways to apply cloud-native development principles not only for your new applications and projects but also to your existing ones. Obviously, your new projects are great candidates for cloud-native development but don’t forget about your existing applications, which can gain from running on a cloud-native platform. Lastly, remember that shifting your software development life cycle is a journey and not something you can do overnight

JAXenter: You’ve mentioned to me that there are eight steps that will lead organizations to a cloud-native future. Tell me a bit about those.

Moving to cloud-native development is a journey and a learning experience; it’s not something that can happen from one day to the next.

Cesar: 

1. Evolve a DevOps culture and practices
   • In order for IT organizations to develop and deliver business functionality faster, development and operations teams need to evolve in the way they work and collaborate with each other. The adoption of a DevOps culture relies not just on tools and technologies, but also on the willingness and trust of people to embrace a more integrated and collaborative approach to developing and delivering applications. The culture of open source software projects can be a guide to building a DevOps culture.
2. Speed up existing, monolithic applications
   • Organizations cannot throw away their existing monolithic applications, which have been running their businesses effectively all these years. However, you can speed these existing applications by migrating them to a modern container-based platform, which, among other benefits, can improve automation and development speed. You could then identify components of your monolithic application that can be exposed using APIs. Furthermore, you could also start breaking up your monolithic applications into microservices or miniservices, using runtimes that best solve the problem in the separated services.
3. Use application services, i.e., middleware, to speed up the development of business logic
   • Reusability has always been key to speeding software development, and cloud-native applications are no exception. Why re-create a caching service, rules or workflow engine, integration connectors, mobile and API management capabilities, data virtualization service, messaging brokers, or serverless framework when you can use existing ones that have been optimized and integrated to the underlying container-based infrastructure? These application services, whether they are Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), or iPaaS offerings, are effectively ready-to-use developer tools. Use these reusable components for cloud-native applications and preferably ones that have been optimized and integrated into the underlying cloud-native infrastructure to fully reap their benefits.
4. Choose the right tool for the right task
   • Organizations are selecting the best tool, from a variety of runtimes and frameworks, to solve a specific task. Building cloud-native applications is becoming more diverse as the choice of language or framework is increasingly tailored to the specific business application needs. The resulting increase in complexity merits use of a container-based application platform that supports the right mix of frameworks, languages, and architectures to support cloud-native development. There are many technologies and frameworks to implement cloud-native applications, e.g., Quarkus, Spring Boot, Eclipse MicroProfile, Eclipse Vert.x, DropWizard, Python, Apache OpenWhisk, Node.js, Golang, and Jakarta EE. Depending on the problem you’re trying to solve, choose the tool/framework that will best help you solve it.
5. Provide self-service, on-demand infrastructure for developers
   • Self-service and on-demand infrastructure provisioning provides a compelling alternative to unauthorized shadow IT by allowing developers to access the infrastructure they need, when they need it. But this model can only be effective if IT operations teams have control and visibility across what is often a dynamic and complex environment. Containers and container orchestration technology abstract and simplify access to underlying infrastructure and provide robust application life-cycle management in a standard way across various infrastructure environments, such as data centers, private clouds, and public clouds. They offer additional self-service, automation capabilities. This model lets developers and operations teams spin up consistent environments quickly, helping developers focus on building applications without the obstacles and delays associated with provisioning infrastructure.
6. Automate IT to accelerate application delivery
   • The idea here is to adopt an enterprise-wide, programmatic automation approach to IT operations. IT management and automation tools create repeatable processes, rules, and frameworks that can replace or reduce labor-intensive human interaction that delay time to market. IT and infrastructure automation is essential to accelerating the delivery of cloud-native applications by eliminating manual IT tasks. Automation can integrate with and apply to any task or component, from network and infrastructure provisioning to application deployment and configuration management. As a result, automation is an important aspect of IT optimization and digital transformation, speeding overall time to value.
7. Implement continuous delivery and advanced deployment techniques
   • CI/CD deployment pipelines enable code changes to be pushed to production faster and more reliably to provide fast feedback to developers. This iterative, fast feedback loop is enabled through CI/CD, extending infrastructure automation to an end-to-end, automated delivery system that covers all aspects of application delivery, including automated testing, vulnerability scanning, security compliance, and regulation checks. The goal of automated delivery pipelines is to provide updates without affecting operational capacity, helping to reduce delivery risks. As far as advanced deployment techniques, one is rolling upgrades. This is a deployment in which you use a router to temporarily take a server offline while you apply an update to it. This approach enables you to apply an update to your application with no perceptible downtime to the end user. Another advanced deployment technique is Blue/Green deployments. In this type of deployment your blue “live” workload is your production workload. You then introduce a modified green workload to production and redirect traffic to it using a router. If everything proves to work well, then you can retire the Blue deployment. The next advanced deployment is Canary deployment, which is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. Lastly, A/B testing is a deployment technique to test a hypothesis using variant implementations. You bring the variant online to a segment of users and gather key business metrics. It can take days to gather enough data to demonstrate statistical significance from an A/B test. The overall goal of these advanced deployment techniques is to apply changes to a production system with little to no risk of downtime. Furthermore, they can leverage the underlying CI/CD deployment infrastructure as part of their automation.
8. Evolve a more modular architecture
   • There are many ways to evolve a more modular architecture. In a microservices architecture approach to writing software, applications are broken down into their smallest components, independent from each other. Microservices architectures are a great fit for building cloud-native applications in that they fulfill the development concerns of cloud-native application development, namely the Service-based and API-driven tenets. However, microservices architectures are not easy to implement or maintain. It is because of this that subject matter experts recommend an alternative called MonolithFirst, which is an approach to microservices, which proposes building an application as a monolith first even when your intention is to create a microservices architecture. The goal is to first understand the domain of your application well so that you can better recognize bounded contexts within it that would serve as candidates to convert into microservices. By doing so, this approach avoids technical debt, such as repair costs when building a set of microservices before understanding the domain and bounded contexts of the application. No matter what route you choose to evolve a more modular architecture, taking your first step into doing it is what’s important in your journey to cloud-native development.

JAXenter: Which of those steps poses the biggest challenge, would you say?

Cesar: There are two steps that are challenging to organizations.The first one is evolving a DevOps culture and practices. Introducing change to any organization that modifies the way it conducts its day-to-day activities is always disruptive. It’s in people’s nature to get in their comfort zone and stay within it. I remember when I was a young developer, peer code reviews were introduced into the development life cycle and it caused an uproar in the IT organization because developers, by nature, took great pride in what they wrote and did not take well to criticism of their code by others, especially face-to-face. And this was a small change. Imagine trying to evolve from two separate departments, operations and development, each with its own well established procedures and missions, to a single DevOps culture that introduces a completely new organization structure with a different mission and processes!

SEE ALSO: Serverless and DevOps in 2020 – “Going serverless is a great way of cutting costs”

Although difficult, like with any innovation, it takes time for organizations to adopt DevOps culture and practices. IT leaders understand the benefits that a DevOps culture brings to their departments and are adopting DevOps culture and practices despite its challenges because they understand that in the long run, the payoff is much greater than the pain it takes to transform. The second challenging step is evolving a more modular architecture. The danger here lies in the eagerness of organizations to adopt an innovation hastily. Great innovations are transformative by nature and take time to adopt.

Because of the great benefits that microservices offer and the synergy and support they provide to cloud-native development, many organizations mistakenly see microservices as a panacea for all of their IT problems. Most successful organizations already have existing and legacy systems, many of which are not based on cloud-native principles, and they are faced with the challenge of adopting new approaches to accelerate the software development life cycle. To be successful in evolving a more modular architecture, you must take a phased approach and take your time in carefully identifying and selecting existing applications and systems to make more modular and apply the same philosophy to new projects as well.

JAXenter: Finally, do you have any advice or best practices for those who are considering moving to cloud-native application development, or those who are already on the way?

Cesar: Moving to cloud-native development is a journey and a learning experience; it’s not something that can happen from one day to the next. If you’re a startup, you can start doing cloud-native development from the get-go. However, many organizations are well established and have complex IT environments that span from on-premises applications to cloud services and platforms. In addition, most organizations are not Netflix or Uber, in that they cannot homogenize all of their systems and platforms into a single architecture. Instead, most organizations need to start from a non-cloud-native state. How to best start? My advice is to not try to boil the ocean when it comes to start cloud-native development. Start small and incrementally. Here is some guidance on how to do it:

1. Migrate your monoliths and applications to the cloud first. If you have any data compliance or government regulation that prevent you from moving to a third-party cloud then migrate to your own on-premise cloud.
2. Containerize workloads that can run on containers and container orchestration platforms. Remember to containerize even the monoliths because you will gain delivery speed and integration benefits by doing so.
3. Identify monoliths (or portions of them) that may be eligible to be broken into microservices or serverless function calls. Remember that some monoliths may be non-breakable. Look at services or functionality that are not called often and consider turning them into serverless function calls.
4. For your green field applications, start using your cloud-native platform in combination with application services to speed up the development of business logic and the delivery of these apps to the line of business.
5. With every service, monolith, or third-party application running on the cloud platform, leverage cloud services, e.g., integration, API management, business process automation, decision management, etc., that have been engineered to work together and optimized for the underlying cloud platform so that they don’t get in your way of developing business logic.
6. Learn and improve. As you become more familiar with the changes in the way you develop and deliver solutions to the business, remember to adjust processes so that your developers can become more and more efficient as your organization evolves into cloud-native development.

Thanks very much!

The post 8 steps towards cloud-native development appeared first on JAXenter.