[This is Part I of a series of research focused on the technologies and architectures within the new cloud-native stack. Part II is available here – “Emerging Architectures for Cloud-native Applications“]
Premise: As the cloud-native application landscape rapidly evolves, the number of technology choices that IT organizations and digital product teams face is growing at an unprecedented pace. Factors such as existing application portfolios, existing technical skills, the ability to hire new skills, and using public cloud-based services or build internal systems all play a critical role in understanding the breadth of choices available and the trade-offs involved with each choice.
As more businesses evolve through digital business transformation, the opportunity for application developers to address new market challenges has never been greater. Moreover, with the widespread availability of both public cloud services and freely available open-source software, the ability of developers to build new digital business applications has never been easier. But selecting which technologies to use to create those applications, and especially how to build the digital business platform, has never been more difficult.
In evaluating how to approach the breadth of technology choices available, it important to include these three critical elements into any action plans:
- Determine the starting point or existing status of applications. Business transformations can have many different starting points. They may begin with modifications to an existing application to allow it to work with new environments (e.g. mobile devices). They may also begin as a completely greenfield project. It’s critical to understand the desired business goals as the existing starting point in order to map the technology steps along the way.
- Understand the technology options of each application status. Whether an application needs to be modified or is a new build, it’s critical to understand your system options, especially which technologies can benefit the applications from predictability, scalability, security, cost effectiveness, and experience effectiveness standpoints.
- Evaluate the basic risks/choices at each option. Both public cloud and open source have significantly changed how technology is acquired, consumed, and managed. Acquiring technology has never been easier; adopting it — catalyzing the people changes necessary to get value out of that technology — remains a huge challenge. It’s important to consider how well prepared the IT organizations and digital product teams would be in adopting any technology.
Migrating The Current Application Portfolio
Different approaches for evaluating an application portfolio are best given different contexts. For the context of moving to a modern application environment, incorporating automated, programmatic, and cloud-native delivery models, Wikibon believes companies need to segment existing and new applications into three groups:
- Existing applications that are running in a virtual machine (VM).
- Existing applications that are running on bare metal machines.
- New applications.
The model assumes that IT organizations and digital product teams are looking to move to a modern application environment, incorporating automated, programmatic, cloud-native delivery models.
For applications that are currently virtualized, which are primarily stateful applications, there are multiple migration options (see Figure 2):
- Maintaining the application “as-is” and maintaining the existing hypervisor. In each case, there are options to [a] make no changes to the application, [b] modify/rewrite the application to become more modular and leverage container-based delivery models, [c] migrate the application to a public cloud service (AWS, Azure, GCP) which supports the existing technologies.
- Migrate the existing application to a new hypervisor (Xen, KVM, Hyper-V), which may allow a simpler migration to alternative private cloud, managed private cloud, or public cloud service frameworks.
For applications that currently reside on bare metal systems — and can be migrated — two migration paths are options:
- Migrate the application to a virtualized environment (VMware), which potentially provides cost-reduction, performance improvements and greater application agility by simplifying upgrades and additional migrations.
- If possible, re-architect and modify/rewrite the application into a more modular form that can take advantage of container-based delivery models. This could be a complicated process, especially if it requires the application to initially be ported to another platform and x86 operating system (e.g. away from a proprietary UNIX systems).
The Emerging Application Portfolio
Associated Wikibon Research:
- Cloud Native Platforms – http://wikibon.com/cloud-
native-application-platforms- structured-and-unstructured/ - Container Ecosystems – http://wikibon.com/
container-ecosystem-unlocking- the-speed-of-developers/ - Evolving Container Architectures – http://wikibon.com/evolving-
container-architectures/ - Managing and Operating Docker Containers – http://wikibon.com/docker-
is-the-least-interesting-part- of-docker/ - Realities of the New Infrastructure Stack – http://wikibon.com/
realities-of-the-new- infrastructure-stack/
As IT organizations and digital product teams begin building new cloud-native applications, the number of technology choices available to them rapidly expands. ‘These choices need to be understood from the perspectives of end-user requirements, vendor selection, procurement models, SLAs, operational models, hiring and organizational culture. The primary considerations become:
- Should the application continue to be operated within an on-premises environment, or moved to a public cloud to take advantage of automated, scalable services?
- What will be the role of application developers in deploying and maintaining the application vs. the role of operations teams or public cloud services?
How comfortable are existing IT organizations and digital product teams with using open source technologies and leading-edge technologies?
Build Directly With Public Cloud Services: For most new cloud-native applications, it makes sense to leverage the breadth of public cloud IaaS, PaaS and SaaS services (Wikibon public cloud forecast; big data in the public cloud forecast). They provide a global footprint of on-demand resources that allow developers the flexibility to choose the services that will best help them deliver applications to serve customer demand and grow the business.
Build With Containers; Manage Deployment Options: The use of containers by developers has been growing exponentially for the past two years, especially with Docker. This simplified packaging method allows developers to consistently transition applications from their laptop through the development lifecycle (Dev, Test, Staging, Production). The container model allows application artifacts to become the input to many systems, including Platform-as-a-Service (PaaS), Containers-as-a-Service and a wide variety of public cloud container management services. Each of these options provide developers with choices about the runtime environment for their application. The benefit of using containers is that the developers will have a consistent experience, regardless of what operational model is chosen by the operations teams.
Directly Pushing Code From Developer To Platform: While some developers are comfortable with packaging their code and applications in a container format, others would prefer to build and update their applications by directly pushing code into the CI/CD system or operations platform. In today’s marketplace, many choices are emerging which provide a tremendous amount of assistance to developers to build applications.
PaaS platforms allow developers to directly push code or entire applications into the system. These PaaS platforms provide different levels of scalability, as well as options such as open-source technology and public cloud consumption models. Technologies such as Cloud Foundry, Kubernetes, Mesos/Marathon, Open Deis and others play a key role in shaping the architecture of these platforms.
“Serverless” platforms are emerging as a simplified version of PaaS, where developers only need to focus on delivering functional elements of the application, while the platform manages all aspects of scalability and performance. Offerings from AWS (Lambda), Azure (Functions), Google Cloud (Functions) and IBM (OpenWhisk) are delivering a wide variety of options to allow developers to focus less on resource planning and more on granular elements of application interactions.
Mobile Backend as a Service (MBaaS) platforms have also emerged, with a focus on mobile applications. These frameworks allow mobile developers to primary focus on client-side and UI/UX challenges, while the MBaaS handles the majority of the backend functions (authentication, performance, scalability, database and data management). Companies such as AWS, Azure, Firebase (Google), Kinvey, Oracle and Parse (Facebook) have been early leaders in this market segment.
People Considerations Remain Crucial To Achieving Goals
As with any technology choice, there are always tradeoffs between “ownership” and “control”. With new cloud-native applications, the ownership aspect can involve not only physical ownership of resources, but more importantly will involve (or not involve) the ownership of the underlying services operations. The control aspect is focused on things like performance management, troubleshooting and data sovereignty, but it is offset by the challenges of finding the technical skills needed to manage the underlying resources and services. Far too many companies under-estimate the complexity of operating on-demand services, especially if that operating model is a departure from existing IT operating models. Wikibon has researched the market impacts of these trade-offs at the IaaS level, as well as the best practices of companies that have successfully made this transition.
Action Item: As IT organizations and digital product teams begin to think about the evolution of their application portfolio, it is critical to begin with the end in mind. That end could be cost reductions and licensing agility, or it could be new customer experiences on new platforms. Envision end results first, then use that decision space to choose the right path through the breadth of available technology choices.
