CUTTER IT JOURNAL VOL. 28, NO. 10
  

Cloud-related discussions are happening everywhere. One topic that is both interesting and has a lot of potential is how to build and operate the new applications tailored for the cloud environment. To a great extent, it is a very technical discussion, but as it can have a profound impact on the business and operational model, it should not be ignored by anybody serious about capturing the value of cloud computing. In this article, I give an overview of how to design, build, and operate a new breed of cloud-native applications. I will also look at how cloud-native design positively impacts a business, bringing new and crucial capabilities to your organization.

CLOUD-NATIVE DESIGN? WHAT'S THAT?

Like any other information technology, cloud requires a specific approach from developers. In order to benefit from the features that cloud computing offers us, it is important to adapt to the technology and its specifics. There are different terms used to describe how well (or how poorly) an application is prepared to run in the cloud. The most common are cloud-centric, cloud-enabled, and cloud-native, which are used in many contexts and very often interchangeably. As these are not official definitions, I have taken the liberty of putting them on one scale so the clear "progression toward cloud nirvana" can be seen (see Figure 1).

Two questions arise instantly:

1. Do we want to move toward cloud-native design, and is that our ultimate aim?

2. How do we design (or redesign) our application and organization so they fit the cloud world?

The first question I will try to answer later in the article. The second one points toward some kind of standard, pattern, or method for designing cloud applications. Thankfully, some smart people have already explored cloud design patterns and shared their thoughts publicly. There are two major "manifestos" that can guide developers and help them to achieve the status of "cloud wizards":

• The Twelve-Factor App¹ is a 12-point methodology that ensures your application will be suited for the cloud. It focuses on functional requirements that every application should meet in order to be fit for the cloud environment.

• The Reactive Manifesto² offers four very crisp points on the qualities every cloud application should possess. It can be compared to the generic nonfunctional requirements.

There are many other guides, words of advice, analyses, and architectural patterns that describe different aspects of planning, designing, and coding cloud-centric applications. Some of them embody specifics of the given cloud platform, programming language, or type of application. I therefore encourage everybody to explore relevant materials in depth.

MICROSERVICES: A PARTICULAR ARCHITECTURAL PATTERN

Scalability, elasticity, and adaptability -- these are the terms commonly associated with the cloud, and so should they be with your cloud application. One way to achieve such flexibility is to decompose your design into many independent parts: namely, microservices (see Figure 2).

A microservice is an architectural pattern in which we try to isolate the smallest possible application functionality within the independent module. We also want to make sure that each and every one of those modules is elastic and can scale horizontally so it never becomes a bottleneck for the performance of the entire system. Thus, microservices should be stateless, message-driven, and responsive. If one instance goes down, a different one will take over.

Another important feature of microservices is how they deal with errors. Overall, we could discuss two opposite approaches to handling the unexpected. One states that you should capture and appropriately react to each and every error your application can throw at you. You should focus on error resilience, error handling, and error management. Nothing can be a surprise to your application! The second is to embrace the errors. Let them flow! It's better to fail gracefully and restart quickly than try to handle every possible situation. Cloud-native design (and microservices) embraces the latter approach.

A LIGHTWEIGHT CONNECTIVITY

Along with microservices, cloud-native design promotes the use of application programming interfaces (APIs). Although this idea is not new, its popularity is growing rapidly along with the broad adoption of different kinds of platforms. APIs help to keep the architecture modular, where different modules can be developed independently at their own pace. Platforms like OpenStack, Cloud Foundry, Bluemix, Facebook, Twitter, and many others expose their functions via APIs to enable partners and third-party developers to add functionality on top of them.

There are two main reasons why APIs are important for cloud developers:

1. You will need to consume APIs exposed by the cloud platforms you will most probably use.

2. You will want to expose the functions of your microservices via APIs so you can easily connect them with other modules and services.

If you have had an opportunity to work with SOA, you will definitely notice the similarities between the two concepts. Figure 3 outlines the most visible differences, showing APIs as a lightweight version of the SOA approach.

The API concept also has a profound impact on business. It enables organizations to expose their services and data so that they are very easy to consume. The API economy aims at creating a partner ecosystem of organizations and people who use your data or services in a way that brings additional value to the end customer.

FORGET ABOUT HARDWARE

The rise of software developers can be traced back to the 1950s, when Fortran was created. It was the first widely adopted programming language that allowed for the decoupling of hardware and software through the use of high-level instructions. Unfortunately, even then programmers had to take into account the specifics of the underlying IT infrastructure. Virtual machines and script language interpreters helped to abstract the programs even more, but at the end of the day, programming was always dependent on the infrastructure preparation. Installing and configuring the server, network, and storage were necessary prerequisites. It took time, and it was a distraction from the real aim of programming, which is coding the business functionality.

With cloud computing, the need for hardware platform–specific knowledge is fading away. Today programmers can focus on ... programming. PaaS brings the promise of an always ready, always available, and always up-to-date software development environment. This can be achieved by introducing an abstraction layer between the hardware and software. One of the most popular and fastest-growing open source platforms serving this purpose is OpenStack.

OpenStack is a modular standard dealing with different domains associated with IT infrastructure. It handles the setup and configuration of storage, networks, and computation nodes. Thanks to a broad development ecosystem, it supports most of the hardware components available on the market. Its standardized API allows programmers to dynamically manipulate and configure the technical environment according to the requirements, workload levels, and other runtime parameters. OpenStack is a platform where hardware adjusts to the software, and the concept of "software-defined everything" becomes a reality. No more screwdrivers nor low-level console commands. Everything can be managed using standardized high-level API calls.

Another standard that makes things easier for developers is Cloud Foundry (see Figure 4). It is an open source platform that supports the full application lifecycle starting from initial development to testing, deployment, and operation. Its built-in features made it a natural match for DevOps³ and continuous delivery. In addition, Cloud Foundry enables application autoscaling, logging, and version control; supports distributed filesystems; and delivers many other out-of-the-box features. In short, this platform is designed with the cloud environment in mind, and it is a perfect fit for cloud-native apps. As an example, the IBM Bluemix PaaS is built on top of Cloud Foundry, adding many ready-to-use technical and business services that support analytics, Internet of Things, mobile, and other domains.

NEW, POWERFUL TOOLS

With the advent of cloud-native design, new tools, languages, and concepts appear. New (and not so new) languages like Node.js, Ruby, and Go are used to build lightweight, very responsive, and RESTful applications. Very often they deliver ready libraries for the most common operations, connectivity, security, and logging so developers do not have to reinvent the wheel and can focus on coding essential business functionality. Other standard components, like databases, are exposed as a service as well. Installing and configuring a database is no longer required in the cloud world. One very popular DBaaS platform is IBM Cloudant, which is based on the Apache CouchDB open project. Not only is it available through the Internet, exposing RESTful APIs for data manipulation, it is also a NoSQL database. This means there is no specific schema definition needed, and changes to the data structure can be done on the fly. There are a few types of NoSQL databases, such as graph, map, or document databases. Cloudant uses the JSON standard to store the data as documents. It is perfect for distributed, highly scalable, and responsive Web-based applications. Together with the Node.js language, which also supports JSON natively, they make a perfect match for cloud-native apps.

Another technology that is gaining great traction and popularity within the developer community is containers. Docker, a specific implementation of this concept, is already widely used and supported by most of the cloud platforms (see Figure 5). A container allows programmers to package their application together with everything necessary to run it: code, system libraries, and tools. This package (called a "container") can be deployed on any other system, ensuring that it will work as designed. Containers are often considered a lightweight version of the virtual machine.

On top of new languages, databases, and containers, there is a growing portfolio of tools delivered only in the form of public cloud services. We can see many examples of such offerings in the area of advanced analytics. There are numerous reasons why these services are not sold in an on-premises model, such as:

• The high entry cost for the underlying infrastructure makes it commercially unattractive if it is not sold as a public service.

• A public service allows better control over who is using state-of-the-art solutions and how.

• A public service offers better versioning control, thus allowing for instant bug fixing.

Introducing cloud-native design and opening your software products to the public (or at least an off-premises) cloud enables your business with a new set of tools that otherwise would be not available.

WHY SHOULD WE CHANGE THE WAY WE WORK?

On top of all the changes in software engineering enforced by cloud technologies come changes in techniques, approaches, and our mental attitude toward application design, development, and operation. One very important feature of the "new" way of working is user centricity. Mobile apps development taught us that people will simply not use poorly designed or nonresponsive applications. Therefore, everything we do should focus on user experience. Users as well as business departments expect that the new breed of cloud-native applications will evolve, quickly adjusting to the new requirements. New features and fixes of known bugs should be delivered instantly without impacting business continuity. These expectations require changes in how designers, developers, and administrators work and collaborate (see Figure 6).

Much has been written about Agile and the benefits of using delivery methods like Scrum. But in order to use cloud to its full potential, it is crucial to look at the entire application lifecycle. Agile methods address the design and delivery stages well, but the requirements gathering/planning phase and moving from deployment to maintenance/operations are equally important. As cloud-native design focuses on user centricity and speed of delivery, appropriate methods and practices should be implemented to address the commonly known issues.

The traditional approach to the planning and requirements gathering phase focuses on the functional features of the future software. It does not give much insight into how this application will be used by the end users. As a result, design (and, later on, development) is driven by many not always correct assumptions. This is where design thinking can help. By focusing on the user and how the software will be used, architects and designers can get better insights into what is really needed. Instead of asking what features a given application should have, design thinking tries to discover what the end user wants to achieve by using the application. IT professionals can then design the application guided by a combination of these insights and business and usability best practices. This approach enables them to deliver a delightful user experience, which solves the specific business problem in a way that the users could not have envisioned themselves.

Another deficiency that prevents organizations from leveraging the cloud's speed of delivery appears after software is put into production. The team that knows the app the best is the operations team — they work with it every day, they handle the errors and complaints from the end users, and they know what could be done better. Unfortunately, many times this team is separated from the development team; communication therefore takes more time and requires unnecessary overhead. Misunderstandings and unclear requirements further impede the delivery of new fixes and versions. DevOps addresses this gap by bringing development and operations practices together, thereby enabling continuous delivery. In the DevOps world, adjustments and enhancements are introduced as often as needed; the quarterly release strategy becomes obsolete. The most famous example of a working DevOps practice is Netflix, where changes to the production platform are introduced as many as 100 times per day.

In summary, cloud-native design requires changes not only in the tools, design, and platforms we use, but also in the way we operate our software solutions. Design thinking, Agile, and DevOps are not the only ways to leverage cloud-native design, but they are definitely good places to start.

THE PROMISE OF CLOUD-NATIVE DESIGN

Cloud-native design holds a lot of promise. Despite the effort needed to set up the tools, methods, and organizational practice around this approach, more and more organizations are following the successful implementations proven by Netflix and Amazon. But this is not a purely technology-driven trend. Adjusting all parts of your organization to work in a new way will enable your business to gain agility, which is crucial in a digital world. Below I discuss the four most important benefits that come from cloud-native design.

Flexibility

Using the microservices architectural pattern together with the proper implementation of DevOps practices should increase the speed at which your product can evolve. Consequently, innovation can be delivered faster. In a digital world, the ability to rapidly enhance, change, and improve your product is crucial. Being first is a very successful strategy. By decoupling the functions of your product, it is possible to introduce multiple development paths with different speeds and release strategies. Integration based on APIs can help to reduce dependencies between modules, applications, and the front and back ends.

Scalability

Digital business does not have geographical boundaries. It is safe to assume that for every business that can be digitized, there is a whole world of opportunities. Rolling out your solution to new countries has never been easier. Cloud-native design helps to prepare for rapid growth of data and your user base; high availability and theoretically unlimited scalability are two of the most important benefits of the cloud. The pay-as-you-grow model makes CAPEX investments obsolete. Thanks to the IaaS, PaaS, and SaaS cloud models, your organization does not have to become asset-intensive. Instead, you can balance your spending on technology with the current size of your business.

Portability

In a fully hybrid cloud environment, your cloud-native product can work on any infrastructure from any vendor anyplace in the world. It is impossible to predict which vendor will come up with better and cheaper technology. Therefore, staying vendor-neutral is a very good strategy. By using widely adopted standards (such as OpenStack, Cloud Foundry, and containers), it is possible to dynamically manage deployment of your workloads. Cloud-bursting techniques allow you to expand your on-premises cloud with the capacity delivered by off-premises platforms.

Automation/Self-Service

The cloud environment is based on standards, reuse, and automation. Those characteristics allow for competitive pricing, which reduces the manual labor needed to set up, configure, and manage IT infrastructure and platforms. On top of automation capabilities, self-service portals are an important part of the overall cloud-native environment. Thanks to them, developers can create necessary environments by themselves -- and it takes only seconds. A well-designed application can scale itself, adjusting automatically to the current demand and the number of users. Both automation and self-service have a profound impact on the costs of operations and administration. They represent a significant business benefit of moving toward cloud-native design.

A new IBM Institute of Business Value report⁴ gives a good overview of how important cloud-related technologies are for the condition and competitiveness of your business. In a digitized economy, technology becomes a core part of the business and is the source of competitive advantage. Introducing cloud-native design helps to capitalize on the market change driven by massive digitization.

IS CLOUD-NATIVE DESIGN A GOOD FIT?

Looking at the full spectrum of platforms, tools, techniques, and methods associated with cloud-native design, the obvious question arises: is cloud-native design the best fit for your organization? As always, there is no one right answer. Your decision should be based on many factors. Also, adapting to the new way of working, new tools, and new platforms can be done in many different ways. Moving to a cloud-native design practice will require time and most probably will generate additional costs. It requires careful consideration as to whether the future benefits, flexibility, and scalability of your product make it worth the effort.

Purpose and Audience

One of the most important factors in deciding for or against cloud-native design is the purpose and audience of your application. If your product is a mission-critical system (e.g., integrated flight system, core banking system), it might be counterproductive to use the cloud-native design paradigm. Such systems are not easily changed, and most of the time they run on dedicated hardware; therefore, the benefits of the cloud might not apply here. There are other more suitable architectural patterns you might use instead. Consider, too, who will be using your application. It is common knowledge that the mass end user is far more demanding regarding the design and responsiveness of an application than the corporate user. The latter is often happy with a simple windowed app as long as he or she does not have to work with black-screen, DOS-like applications. Although with Generation Y this attitude is changing, for corporate, transaction-heavy applications, cloud-native design might be overkill.

Size and Scope

Size matters. There is not much point in designing a sophisticated microservices architecture with highly scalable characteristics if you know that the number of end users for the app will be roughly 100. Likewise, if the planned application will be very limited in scope and not exposed as a service, and if there is no strategy in place to increase its functionality in the foreseeable future, there is also no reason to decouple functional modules. Microservices require additional effort to embed common functions in every instance, and most of the time supporting services are necessary (such as dispatchers, proxies, and load balancers). For small applications, full-blown cloud-native design might not make economic sense.

Team Culture and Maturity

Cloud-native design requires both technological and organizational change. It might be increasingly difficult to push for "doing things differently" in a mature team with years of experience and well-defined procedures and processes. Sometimes the effort needed to change and persuade the team members of the benefits of cloud-native design might come at a price that is simply too high. On the other hand, a certain team maturity is necessary to maintain productivity and avoid wasteful practices. Cloud-native design might bring a lot of tools and practices that will not work for your organization and only cause an increase in the workload. Mature team members will be able to recognize the harmful practices and correct them.

Time and Costs

Moving to cloud-native design requires time and money. It is probably not the best idea to change your design and delivery methods while in the middle of a project with an aggressive schedule. That said, it is also very risky to kick off a pure transformation project, as those tend to be very long, and organizations need to wait a significant amount of time to see tangible results. Regarding cloud-native design as an architectural style, it is not always beneficial to rewrite existing applications in accordance with the new paradigm. Organizations should carefully analyze whether it would be more cost-effective to modify existing apps or create new ones from scratch. Both time and costs will depend also on the adoption approach your organization chooses, as I discuss in the next section.

APPROACHES FOR ADOPTING CLOUD-NATIVE DESIGN

Should you decide that introducing cloud-native design is the right strategy for your organization, there are a variety of ways to go about it.

All or Nothing

This scenario assumes a binary decision. You either stick to your well-known, optimized, and procedural way of designing and operating, or you move completely to the new way of doing things. This approach fits best those organizations that are unable to keep up with market demands any longer. If you are under paralyzing pressure from the competition and always-growing, always-unfulfilled demands from your end users, it might be time to revolutionize your entire delivery model. Changing your tools and methods, redesigning your product, and adjusting how your organization operates might be the only way to survive.

The all-or-nothing scenario requires an immense amount of focus on organizational change management. Most of the time, it also requires a fundamental change of the organization's culture. You can be sure of resistance from all sides. (All this in the name of the greater good.) In big organizations, such transformation projects can easily take two to three years before producing the first noticeable results.

Learn As You Go

This scenario aims at introducing incremental improvements -- evolution rather than revolution. It is most suitable for organizations that noticed the change in the market early enough. There should be a consensus among teams and management that, in order to continue growing, things need to change. Setting up a group of coaches and "architects of change" is a good practice. They will show others the way, but the learning and change will come organically from the team members.

Trainings and enablement sessions are crucial to building awareness among employees. Improving the delivery pipeline by gradually moving toward DevOps practices at the same time that you decouple parts of your products will bring the flexibility. This, in turn, will increase the responsiveness of your delivery organization. The learn-as-you-go method almost always ensures that a new organizational culture will emerge.

Proof of Concept

This scenario relies on the introduction of "two-speed IT." On the one hand, you keep things as they were and focus on sustainability and further optimization. On the other hand, you create a small unit, department, or team that works according to the new cloud-native rules. This approach is most appropriate for medium and big companies where the all-or-nothing method is too risky and the learn-as-you-go method will take too long.

Treat the effort like a managed revolution — starting small, collecting lessons learned, adjusting the approach, and finally rolling out the change to the entire organization. A recent article by researchers at McKinsey⁵ offers advice on successfully implementing a two-speed IT operating model.

GOING NATIVE

Cloud-native design, with all its associated methods and practices, is definitely an approach worth considering. Although the topic itself touches a lot of technical aspects, the driving arguments behind adopting this "new way of working" are coming from the business. In the cloud context, technology is an enabler that helps organizations achieve better results in a shorter time with smaller investments. In a digitized economy, business agility is driven by technology, and cloud-native design helps to align technical capabilities with the market strategy.

ENDNOTES

¹The Twelve-Factor App.

²The Reactive Manifesto.

³ Sharma, Sanjeev. "Adopting DevOps for Continuous Innovation." IBM developerWorks, 2 June 2014.

⁴ Brown, Doug, et al. "New Technology, New Mindset: Strategic IT Infrastructure to Compete in the Digital Economy." IBM Institute for Business Value, 2015.

⁵ Bossert, Oliver, Martin Harrysson, and Roger Roberts. "Organizing for Digital Acceleration: Making a Two-Speed IT Operating Model Work." McKinsey & Company, October 2015.