eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Enterprise cloud-native applications are built to take advantage of cloud-computing models that increase speed, flexibility and quality, while reducing deployment risks. Despite its name, a cloud-native approach is not focused on where applications are deployed, but instead on how they are built, deployed and managed.
Evolving toward cloud-native application development and delivery is multidimensional, affecting culture, processes, architecture and technology. As such, this is a journey rather than a destination, representing a cycle of change that can be challenging to embrace.
Cloud-native application development is an approach to building and running an application that can take full advantage of the cloud computing model based on four key tenets: services for architecture, APIs for communication, containers for infrastructure and DevOps for process. Not only should organizations embarking on a cloud-native application development journey consider applying this approach to net-new applications but also to existing ones.
In this eWEEK Data Point article, Red Hat Linux offers its expertise to put cloud-native application development in business context and provide eight steps companies can take to help smooth the path — both technologically and culturally.
Data Point 1: Evolve a DevOps culture
The path to cloud-native applications can require the development and IT operations teams to evolve in many different ways to build and deploy apps faster and more efficiently, as well as bringing in test/quality and security teams as a part of the process rather than a final step. 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.
Data Point 2: Speed up existing applications using a fast monolith approach
Although monolith applications are often associated with a lack of agility, this reputation is mostly due to the way they are built. Many existing applications are critical to business operations and cannot simply be replaced; rather, they need to be integrated with new cloud-native applications. To help speed up an existing monolith, organizations can take a fast monolith approach by moving existing monolithic architecture to a more modular, service-based architecture and API-based communication.
A fast monolith approach can achieve many of the agile benefits associated with microservices without the added complexity and costs. But even before applying a fast monolith approach to existing applications, they can be made faster by simply moving them to a container-based platform, which can deliver deployment and delivery benefits while providing a platform to iteratively develop new features or integrations using cloud-native techniques and approaches.
Data Point 3: Use application services to speed up development
Whereas DevOps and containers can accelerate the delivery and deployment of a cloud-native application, application services can accelerate its development. So, why re-create a caching service, messaging service, mobile and API management capabilities, or serverless framework when you can use existing ones that have been optimized and integrated to the underlying container-based infrastructure?
These application services are effectively ready-to-use developer tools, and cloud-native applications may need one or more of these types of services to help developers accelerate development and get new applications to market faster.
Data Point 4: Choose the right tool for the right task
Building cloud-native applications is becoming more diverse as the choice of language or framework is increasingly tailored to the specific business application need. The resulting increase in complexity can merit the use of a container-based application platform that supports the right mix of curated frameworks, languages and architectures to support cloud-native development. Cloud-native developers also should choose the right tool for the right task – no matter the approach, and the container-based platform should offer the right mix of frameworks, languages and architectures to support the chosen development requirements.
Data Point 5: Provide self-service, on-demand infrastructure
Agile methods have helped developers create and update software more quickly, but they can lack an efficient mechanism for timely infrastructure access when and where it is required. Self-service and on-demand infrastructure provisioning provides a compelling alternative to 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.
Containers and container orchestration technology can abstract and simplify access to underlying infrastructure and provide robust application life-cycle management across various infrastructure environments.
Data Point 6: Automate IT to help accelerate application delivery
IT or infrastructure automation is important for helping to accelerate the delivery of cloud-native applications by seeking to eliminate manual IT tasks. Automation can integrate with and apply to a task or component, from network and infrastructure provisioning to application deployment and configuration management.
IT management and automation tools create repeatable processes, rules and frameworks that can replace or reduce labor-intensive human interaction that can delay time to market. As a result, automation is important to IT optimization and digital transformation, helping to speed overall time to value.
Data Point 7: Implement continuous delivery and advanced deployment techniques
Agile development methods evolved to create a model of release early, release often, and DevOps and continuous delivery approaches extend these methods by uniting developers, operations, quality assurance and security teams to improve software delivery processes. As a result, code changes can be pushed to production more quickly and reliably to provide faster feedback to developers.
This iterative, faster feedback loop is enabled through CI/CD, extending infrastructure automation to an end-to-end, automated delivery system that can cover all aspects of application delivery. The goal of automated delivery pipelines is to provide updates without affecting operational capacity, helping to reduce delivery risks.
Data Point 8: Evolve a more modular architecture
Evolving a microservices-based architecture might provide an extra benefit for very large teams or deployments, however, implementing a microservice architecture can require investment and skills that may prove too disruptive. This is where organizations can use a MonolithFirst approach to microservices, which means building an application as a monolith first, even when your intention is to create a microservices architecture. The purpose of this is to first understand the domain of your application, and then better recognize bounded contexts within it that would serve as candidates to convert into microservices, and by doing so, this approach helps to avoid technical debt. Another alternative to microservices is miniservices, a collection of services that are split by domain, which can improve agility and scale without the complexity of microservices-based design and infrastructure; however, Miniservices still require an investment in agile, DevOps, and CI/CD approaches.
These eight steps can guide you on a path to cloud-native application development and help make your journey a success.