Cloud-Native Applications

IT leaders?in charge of?application development are typically responsible for multiple application development teams utilizing different application development platforms. These platforms have often been in place for a decade or more, are well understood by developers and have established operations?procedures.?The topmost currently used application platform is the Java EE application server platform, 40% of which is planned for replacement over the next months.

However,?the last decade has seen multiple innovations in application platforms, such as serverless cloud, containerization, and low-code?tools. Applications built on previous generations of platforms are not competitive regarding business capabilities or developer productivity.

The?factors driving application platform modernization?vary, but the?ever-increasing demand for more customized, more process-oriented, more intelligent applications can only be met by advancing the?application development processes and their supporting platforms in organizations.

The new landscape of application platforms?is replacing traditional applications such as Java EE and .NET application servers and older forms-based environments, as well as other legacy platforms.

Drivers for Platform Change

Factors driving IT leaders to look at application platform modernization include:

? Business users accustomed to sophisticated consumer technology experiences are less willing to accept below-par user experiences, poor application performance, and the slow roll-out of applications.

? Agile development methodologies?and DevOps practices, leading to continuous delivery with high quality, encourage the usage of platforms that support continuous delivery with security.

? Hyperscale cloud offerings have expanded to cover multiple types of application development and services with ubiquitous cloud availability and?high platform security.

? Low-code development technologies have evolved in some cases to enable citizen development of data- and workflow-oriented business applications?and in others to support rapid application development and composition of enterprise application capabilities.

Users of the most displaced application platform, Java EE, are turning to:

? Pro-code platforms for building APIs and services including specialized user experiences, exploiting cloud productivity and self-service through application platform as a service (aPaaS) and other cloud-native services (functions and containers), often also exploiting other cloud platform services such as artificial intelligence (AI) via extensive “cloud integrated platform services” and their associated ecosystems.

? Low-code platforms for business automation by building data and workflow applications, and often extending existing SaaS applications and exploiting these additional SaaS capabilities through APIs. Low-code (and no-code) capabilities also enable new citizen developer experiences for self-service application development by business teams.

? SaaS and “SaaS as a platform,” whereby legacy applications built on legacy platforms — including many custom third-party software solutions — may be replaced by new SaaS capabilities off-the-shelf. The SaaS ecosystems themselves, usually combined with SaaS vendors low-code platforms, provide a powerful application platform environment in their own right.

The Difference Between No-Code and Low-Code

The overused terms “low-code” and “no-code” are confusing IT leaders and teams about which development tools to choose. Leaders should focus on evaluating these tools based on their fit to use cases and skill sets, rather than the labels used to describe the products.

IT leaders and teams are bombarded by vendors promising great benefits, such as speed and ease of use through the use of their low-code or no-code tools. Additionally, business unit leaders are demanding to use more of these tools to enable business technologists (identified as “technology producers” that do not report to IT) to produce apps and automations for their business needs.

Ignore vendor hype and promises, and instead focus on the underlying platform architecture and technology approaches of the tools to find the best fit ones — regardless if they call themselves low-code, no-code or both.

? “No-code” is a marketing term, implying the tool is for non-professional developers.

? “Low-code” tools often support scripting for capabilities beyond only a “no-code” approach.

? Invest in tools that offer prebuilt “blocks,” but beware of tools that are highly specialized solutions.

? Ensure the no-code or low-code approach fits the skill sets of the target developers, whether professional or citizen developers or both.

? Regardless of marketing labels, make sure the tool supports existing integration, automation, and software development life cycle (SDLC) stacks.

When necessary this kind of tool, select types of Interest

The various types of low-code development tools provide different levels of support for the different capabilities, primarily around general capabilities (UX, process orchestration, data support and API integration) but also with some specialist capabilities (multiexperience, decisions/rules and RPA integration via bots). The most common differentiators for low-code development tools are around developer profile and the requirement for?front-end (UX) versus back-end (process/service) support.

While the definitions of these low-code development platform types map on to specific capabilities, vendors often support multiple capabilities across platform types. Such multifunction platforms provide rich support across more use cases in exchange for higher costs.

Cloud-Native Application Platforms

There is no single and universally accepted definition of a Cloud Native application. According to Vamsi Chemitiganti, “It is an application built using a combination of technology paradigms that are native to cloud computing – including distributed software development, a need to adopt DevOps practices, microservices architectures based on containers, API based integration between the layers of the application, software automation from infrastructure to code, and finally orchestration & management of the overall application infrastructure.” Further, Cloud Native applications need to be architected, designed, developed, packaged, delivered and managed based on a deep understanding of the frameworks of cloud computing.

Cloud application platforms usually refer to cloud-based application platforms for developers and software engineers using programming languages like Java, JavaScript, C# and Python (sometimes called “pro-code” not low-code). They are primarily PaaS but the definition now extends to Container as a Service?(CaaS). They all?support cloud scalability?and?modern software development practices such as agile methodologies, DevOps, continuous integration, delivery and deployment, and?“12-factor”?applications (we address the topic further).?They generally?have well-defined and usually resource-based?price models, and?are often used with application development frameworks such as Spring, Quarkus and Node.?Cloud vendors’ CaaS is the most frequently adopted, but requires more work for developers compared to?other offerings such as serverless function PaaS (FaaS) and aPaaS.

For on-premises (own data center), or running solutions in cloud infrastructure?as a service (IaaS)?account, some application platforms and related services can be used as cloud-enabled application platforms (CEAP). These are generally built on Kubernetes but some,?such as Cloud Foundry and VMware Tanzu, are available with other container managers.?There are also portable container services providing multicloud (or “on any Kubernetes service”) capabilities.

Cloud application platforms continue to evolve. They especially provide good support for Mesh App and Service Architecture (MASA)?and for the creation of new business capabilities?exposed and shared via APIs (we address MASA further). They can also be used to extend?applications delivered using low-code technologies, enabling developers to create?APIs?and services accessible from those tools.

The Twelve-Factor Applications

In the modern era, software is commonly delivered as a service: called?web apps, or?software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

? Use?declarative?formats for setup automation, to minimize time and cost for new developers joining the project.

? Have a?clean contract?with the underlying operating system, offering?maximum portability?between execution environments.

? Are suitable for?deployment?on modern?cloud platforms, obviating the need for servers and systems administration.

? Minimize divergence?between development and production, enabling?continuous deployment?for maximum agility.

? Can?scale up?without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

The twelve factors are:

? Codebase: One codebase tracked in revision control, many deploys.

? Dependencies: Explicitly declare and isolate dependencies.

? Config: Store config in the environment.

? Backing Services: Treat backing services as attached resources.

? Build, Release, Run: Strictly separate build and run stages.

? Processes: Execute the app as one or more stateless processes.

? Port Binding: Export services via port binding (it is?the configuration information that determines where and how a message will be sent or received).

? Concurrency: Scale out via the process model.

? Disposability: Maximize robustness with fast startup and graceful shutdown.

? Dev/Prod Parity: Keep development, staging, and production as similar as possible.

? Logs: Treat logs as event streams.

? Admin Prossesses: Run admin/management tasks as one-off processes.

Mesh App and Services Architecture (MASA)

Masa provides the fundamental architectural capabilities that enable applications to support multiple experiences and respond rapidly to digital business demands. MASA provides the architecture for individual applications as well as a strategy for modernizing the entire application portfolio. It provides an evolutionary approach that enables development teams to iteratively modernize their applications in direct response to business priorities.

The three fundamental components of MASA are multiexperience, mediation and multigrained services and the benefits they bring to your business.

Fit-for-Purpose Apps

Optimized experiences should support the specific needs of the different personas that use the application as well as the different capabilities afforded by the devices they are using. At the same time, an optimized experience should ensure that a particular persona has a consistent experience as they move from one device to another.?

The best practice for providing an optimized experience is to build separate, fit-for-purpose apps that align the design, function and capabilities of the app to fit the workflows of individual personas and modalities. Unlike a one-size-fits-all client experience that attempts to support every feature that every type of user wants from the software, fit-for-purpose apps focus in on the workflows that users follow as they perform their specific tasks. This approach provides the opportunity to create smaller purpose-built apps that are easier to design, develop and deploy. This approach also allows the app to be focused on whatever channel the user prefers when performing tasks, whether it’s a web-based app running on a laptop, a mobile app on a phone or a conversational interface.

Multiexperience design requires the backend to be flexible enough to support the different capabilities and workflows of every app in use. Because users don’t always use the same devices, and often switch from one device to another during their working day, the backend must offer a continuous experience.

MASA supports these requirements by implementing the backend functionality as a mesh of services that can be composed to support the specific needs of an optimized fit-for-purpose app. A popular design pattern called?Backend For Frontends (also known as BFF) supports custom workflows for these optimized apps. Such services align with a specific UX. They offer customized APIs that support the specific workflow required by the UX and orchestrate invocations of the generic backend services that implement shared application functionality.

This model enables development teams to rapidly implement new frontends to support new personas or new devices without impacting other apps or services.

Cloud SaaS Ecosystems

Cloud ecosystems?consist of a continuum of?hyperscalers’ platform services and their third-party partners for components and services. They provide platform experiences beyond the typical application platforms and their adoption is typically a more strategic decision. There are two distinct forms of cloud ecosystems that can be used as platforms:

? Hyperscale providers’ cloud integrated platform services (CIPS) are collections of infrastructure, networking, security and operations services for product teams to exploit. Their container-based solutions allow product managers high levels of control and self-management of the infrastructure, as well as custom selections of application framework operations component software. Examples include business capabilities like ERP being provided for Salesforce customers, or third-party low-code platforms for SAP, or hyperscale providers’ AI and machine learning services for big data analytics.

? SaaS as a platform are products of SaaS vendors that combine business applications (with user interfaces) that are also API-accessible business capabilities or services, which can be extended or recomposed into new applications with their (usually low-code) cloud application platform. The technology stack used for the SaaS provides the processes and data services for new business applications, as well as allowing access via APIs to other SaaS, PaaS or on-premises services.

Cloud ecosystems allow organizations to exploit the leading edge technologies from cloud (infrastructure and SaaS) vendors, including their scale and comprehensive partnerships . These hyperscaler’s ecosystems are also interrelated: for example, Salesforce’s?Heroku aPaaS operates on top of Amazon Web Services (AWS), and Heroku’s customers are free to exploit (and pay for) any of the adjacent 200 services from AWS.

Low-Code Platforms

If you need to democratize the Developer Footprint then choose Low-Code platforms. Low-Code development technologies improve time to delivery for?standardized application patterns, such as data input and output via web and mobile, with variable levels of support for workflow and business logic.?There are multiple types of low-code development tools, characterized by using visual development metaphors, high level scripting languages or a combination thereof.

For example, low-code application platforms?support all-in-one application?delivery with their built-in database support. When the application usage is workgroup- or departmental-based, you can exploit newer no-code citizen automation and development platforms.?Complex workflows and business processes can be developed by business analysts using business process automation tooling.

The capabilities and sophistication of?low-code development tools?continue to strengthen, along with their target use cases (see the the paragraph above?"The Difference Between No-Code and Low-Code").

IT leaders and teams must identify and evaluate, when necessary, Low-Code Development Technologies.?But they always need to consider that this technology also introduces strong lock-in and higher tool subscription costs.

From Gartner's articles: "How to Navigate the Application Platforms Market Including Cloud-Native, Low-Code and SaaS"; "Identify and Evaluate Your Next Low-Code Development Technologies"; "Adopt a Mesh App and Service Architecture to Power Your Digital Business'"

From Vamsi Talks Tech's article "The Seven Characteristics of Cloud Native Application Architectures."

From https://12factor.net/