Microservices (also called microservices architecture) is an architectural approach in which a single application is composed of many smaller, loosely coupled and independently deployable components or services. These services (also called microservices) typically have their own technology stack, inclusive of database and data model, and communicate with each other via a combination of REST APIs, event streaming, and message brokers.

Because microservices can be deployed and redeployed independently, without impacting each other or disrupting the end-user experience, they are a perfect match for automated, iterative delivery methodologies such as continuous integration/continuous deployment (CI/CD) or DevOps. 

In addition to being used to create net-new cloud native applications, microservices can be used to modernize traditional monolithic applications.

In a IBM survey of over IT executives, developer executives and developers, 87% of microservices users agreed that microservices adoption is worth the expense and effort.

Developers often deploy microservices inside containers—lightweight, executable application components that combine application source code (in this case, the microservices code) with all the operating system (OS) libraries and dependencies required to run the code in any environment. Smaller, more resource-efficient and more portable than virtual machines (VMs), containers are the de facto compute units of modern cloud native applications.

Containers amplify the benefits of microservices by enabling a consistent deployment and management experience across a hybrid multicloud environment—public clouds, private cloud and on-premises infrastructure. But as cloud native applications multiply, so do containers and the complexity of managing them. Most organizations using containerized microservices also use a container orchestration platform, such as Kubernetes, to automate container deployment and management at scale.

IBM customers find themselves increasingly tasked with improving existing applications, building new applications, and enhancing user experience. Cloud native applications meet these demands by improving app performance, flexibility, and extensibility.

Advantages

• Compared to traditional monolithic apps, cloud native applications can be easier to manage as iterative improvements occur using Agile and DevOps processes.
  
  
• Comprised of individual microservices, cloud native applications can be improved incrementally and automatically to continuously add new and improved application features.
  
  
• Improvements can be made non-intrusively, causing no downtime or disruption of the end-user experience.
  
  
• Scaling up or down proves easier with the elastic infrastructure that underpins cloud native apps.
  
  
• The cloud native development process more closely matches the speed and innovation demanded by today’s business environment.

Disadvantages

• Although microservices enable an iterative approach to application improvement, they also create the necessity of managing more elements. Rather than one large application, it becomes necessary to manage far more small, discrete services.
  
  
• Cloud native apps demand additional toolsets to manage the DevOps pipeline, replace traditional monitoring structures, and control microservices architecture.
  
  
• Cloud native applications allow for rapid development and deployment, but they also demand a business culture that can cope with the pace of that innovation.

Cloud native applications often have quite specific functions. Consider how cloud native applications might be used on a travel website. Each topic covered by the site—flights, hotels, cars, specials—is its own microservice. Each microservice may roll out new features independent of the other microservices. Specials and discounts can also scale out independently. While the travel site is presented to customers as a whole, each microservice remains independent and can be scaled or updated as needed without affecting other services. The following are a few examples of other cloud native applications.

• American Airlines (2:50) partnered with IBM to build a Dynamic Rebooking app that launched during a severe weather pattern. The app improved the customer experience by providing users more information and an improved rebooking process.
  
  
• XComP Analytics (1:56), an analytics platform for education and training, needed to solve an analytics problem, but in the process of correcting one issue, the company was able to develop six new products after engaging with IBM Cloud Garage. The solution included the use of microservices architecture and plugging in IBM Watson to solve specific analytics issues.
  
  
• UBank (2:45) had a business need to improve their home-loan offering and help customers complete the home-loan process. The company's smart assistant app, RoboChat, answered that need and was built using the IBM DevOps toolchain. Customers that used RoboChat had a 15 percent higher home-loan completion rate.
  
  
• A critical point of medical research is to advise doctors on best practices for patient care. However, medical research that reveals best practices takes 17 years to work its way into actual medical practice. ThinkResearch (2:06) uses IBM Cloud to deliver the best medical information at the point of care. By using IBM Cloud infrastructure and managed Kubernetes services, the ThinkResearch DevOps team can focus on innovation and patient care rather than infrastructure.

IBM Cloud Garage provides IBM customers consulting expertise to build scalable, innovative cloud native apps fast. It offers an innovation hub where businesses of all sizes can design and build apps that solve real-world business needs.

Whether creating a new cloud native application or modernizing an existing application, developers adhere to a consistent set of principles:

• Follow the microservices architectural approach: Break applications down to the single-function services known as microservices. Microservices are loosely coupled but remain independent, allowing the incremental, automated, and continuous improvement of an application without causing downtime.
  
  
• Rely on containers for maximum flexibility and scalability: Containers package software with all its code and dependencies in one place, allowing the software to run anywhere. This allows maximum flexibility and portability in a multicloud environment. Containers also allow fast scaling up or down with Kubernetes orchestration policies defined by the user.
  
  
• Adopt Agile methods: Agile methods speed the creation and improvement process. Developers can quickly iterate updates based on user feedback, allowing the working application version to match as closely as possible to end-user expectations.

Cloud native applications frequently rely on containers. The appeal of containers is that they are flexible, lightweight, and portable. Early use of containers tended to focus on stateless applications that had no need to save user data from one user session to the next.

However, as more core business functions move to the cloud, the issue of persistent storage must be addressed in a cloud native environment. This requires developers to consider new ways to approach cloud storage.

Just as cloud native application development takes on a microservices and modular approach, so must cloud native storage. Cloud native data can reside in any number of places— such as event or system logs, relational databases, and document or object stores.

Data location, retention demands, portability, platform compatibility, and security are only a few of the aspects that developers must consider when planning for cloud native storage.

Cloud native vs. cloud enabled

A cloud enabled application is an application that was developed for deployment in a traditional data center but was later changed so that it also could run in a cloud environment. Cloud native applications, however, are built to operate only in the cloud. Developers design cloud native applications to be scalable, platform agnostic, and comprised of microservices.

Cloud native vs. cloud ready

In the short history of cloud computing, the meaning of "cloud ready" has shifted several times. Initially, the term applied to services or software designed to work over the internet. Today, the term is used more often to describe an application that works in a cloud environment or a traditional app that has been reconfigured for a cloud environment. The term "cloud native" has a much shorter history and refers to an application developed from the outset to work only in the cloud and take advantage of the characteristics of cloud architecture or an existing app that has been refactored and reconfigured with cloud native principles.

Cloud native vs. cloud based

A cloud based service or application is delivered over the internet. It’s a general term applied liberally to any number of cloud offerings. Cloud native is a more specific term. Cloud native describes applications designed to work in cloud environments. The term denotes applications that rely on microservices, continuous integration and continuous delivery (CI/CD) and can be used via any cloud platform.

Cloud native vs. cloud first

Cloud first describes a business strategy in which organizations commit to using cloud resources first when launching new IT services, refreshing existing services, or replacing legacy technology. Cost savings and operational efficiencies drive this strategy. Cloud native applications pair well with a cloud-first strategy because they use only cloud resources and are designed to take advantage of the beneficial characteristics of cloud architecture.