What Are Microservices
What Are Microservices
have their own technology stack, inclusive of the database and data management
model;
communicate with one another over a combination of REST APIs, event streaming,
and message brokers; and
are organized by business capability, with the line separating services often referred to
as a bounded context.
While much of the discussion about microservices has revolved around architectural
definitions and characteristics, their value can be more commonly understood through
fairly simple business and organizational benefits:
Code can be updated more easily - new features or functionality can be added without
touching the entire application
Teams can use different stacks and different programming languages for different
components.
Components can be scaled independently of one another, reducing the waste and cost
associated with having to scale entire applications because a single feature might be
facing too much load.
Microservices might also be understood by what they are not. The two comparisons
drawn most frequently with microservices architecture are monolithic architecture
and service-oriented architecture (SOA).
The differences between microservices and SOA can be a bit less clear. While
technical contrasts can be drawn between microservices and SOA, especially around
the role of the enterprise service bus (ESB), it’s easier to consider the difference as
one of scope. SOA was an enterprise-wide effort to standardize the way all web
services in an organization talk to and integrate with each other, whereas
microservices architecture is application-specific.
The post "SOA vs. Microservices: What's the Difference?" goes into further details.
For more on the differences between microservices and monolithic architecture, watch
this video:
Microservices in the enterprise, 2021 - New IBM research reveals the benefits and
challenges of microservices adoption.
Put another way, microservices are an architectural model that better facilitates a
desired operational model. In a recent IBM survey of over 1,200 developers and IT
executives, 87% of microservices users agreed that microservices adoption is worth
the expense and effort. You can explore more perspectives on the benefits and
challenges of microservices using the interactive tool.
Independently deployable
Perhaps the single most important characteristic of microservices is that because the
services are smaller and independently deployable, it no longer requires an act of
Congress in order to change a line of code or add a new feature in application.
But speed isn’t the only value of designing services this way. A common emerging
organizational model is to bring together cross-functional teams around a business
problem, service, or product. The microservices model fits neatly with this trend
because it enables an organization to create small, cross-functional teams around one
service or a collection of services and have them operate in an agile fashion.
Microservices' loose coupling also builds a degree of fault isolation and better
resilience into applications. And the small size of the services, combined with their
clear boundaries and communication patterns, makes it easier for new team members
to understand the code base and contribute to it quickly—a clear benefit in terms of
both speed and employee morale.
Precise scaling
Modernize your applications for interoperability and ROI - Enhance the value of your
existing apps and reduce the cost to maintain them.
Learn more
But another way of looking at the relationship between microservices and DevOps is
that microservices architectures actually require DevOps in order to be successful.
While monolithic applications have a range of drawbacks that have been discussed
earlier in this article, they have the benefit of not being a complex distributed system
with multiple moving parts and independent tech stacks. In contrast, given the
massive increase in complexity, moving parts and dependencies that come with
microservices, it would be unwise to approach microservices without significant
investments in deployment, monitoring and lifecycle automation.
Featured products
One of the key elements of a microservice is that it’s generally pretty small. (There is
no arbitrary amount of code that determines whether something is or isn’t a
microservice, but “micro” is right there in the name.)
With the proliferation of services and containers, orchestrating and managing large
groups of containers quickly became one of the critical challenges. Kubernetes, an
open source container orchestration platform, has emerged as one of the most popular
orchestration solutions because it does that job so well.
In the video "Kubernetes Explained," Sai Vennam gives a comprehensive view of all
things Kubernetes:
API gateways
Microservices often communicate via API, especially when first establishing state.
While it’s true that clients and services can communicate with one another directly,
API gateways are often a useful intermediary layer, especially as the number of
services in an application grows over time. An API gateway acts as a reverse proxy
for clients by routing requests, fanning out requests across multiple services, and
providing additional security and authentication.
There are multiple technologies that can be used to implement API gateways,
including API management platforms, but if the microservices architecture is being
implemented using containers and Kubernetes, the gateway is typically implemented
using Ingress or, more recently, Istio.
Messaging and event streaming
While best practice might be to design stateless services, state nonetheless exists and
services need to be aware of it. And while an API call is often an effective way of
initially establishing state for a given service, it’s not a particularly effective way of
staying up to date. A constant polling, “are we there yet?” approach to keeping
services current simply isn’t practical.
Serverless
Among the primary benefits of microservices architecture are the utilization and cost
benefits associated with deploying and scaling components individually. While these
benefits would still be present to some extent with on-premises infrastructure, the
combination of small, independently scalable components coupled with on-demand,
pay-per-use infrastructure is where real cost optimizations can be found.
Common patterns
Within microservices architectures, there are many common and useful design,
communication, and integration patterns that help address some of the more common
challenges and opportunities, including the following:
You can learn more about these patterns in "How to use development patterns with
microservices (part 4)." IBM Developer also provides a lot of information if you want
to learn about other microservices code patterns.
Anti-patterns
While there are many patterns for doing microservices well, there are an equally
significant number of patterns that can quickly get any development team into trouble.
Some of these—rephrased as microservices “don’ts”—are as follows:
Introduction to microservices
Quick lab: Create highly scalable web application microservices with Node.js
Get started with Java microservices using Spring Boot and Cloudant
Create, run, and deploy Spring microservices in five minutes
Microservices, SOA, and APIs: Friends or enemies?
What is DevOps?
DevOps speeds delivery of higher quality software by combining and automating the
work of software development and IT operations teams.
In practice, the best DevOps processes and cultures extend beyond development and
operations to incorporate inputs from all application stakeholders - including platform
and infrastructure engineering, security, compliance, governance, risk management,
line-of-business, end-users and customers - into the software development lifecycle.
DevOps represents the current state of the evolution of software delivery cycles
during the past 20+ years, from giant application-wide code releases every several
months or even years, to iterative smaller feature or functional updates released as
frequently as every day or several times per day.
Microservices in the enterprise, 2021 - New IBM research reveals the benefits and
challenges of microservices adoption.
Next, quality assurance (QA), security and operations teams would spend still more
months testing the code. The result was months or even years between software
releases, and often several significant patches or bug fixes between releases as well.
And this “big bang” approach to feature delivery was often characterized by complex
and risky deployment plans, hard to schedule interlocks with upstream and
downstream systems, and IT’s “great hope” that the business requirements had not
changed drastically in the months leading up to production “go live.”
To speed development and improve quality, development teams began adopting agile
software development methodologies, which are iterative rather than linear and focus
on making smaller, more frequent updates to the application code base. Chief among
these methodologies are continuous integration and continuous delivery, or CI/CD. In
CI/CD smaller chunks of new code are merged into the code base every one or two
weeks, and then automatically integrated, tested and prepared for deployment to the
production environment. Agile evolved the “big bang” approach into a series of
“smaller snaps” which also compartmentalized risks.
So DevOps grew out of agile. It added new processes and tools that extend the
continuous iteration and automation of CI/CD to the rest of the software delivery
lifecycle. And it implemented close collaboration between development and
operations at every step in the process.
Featured products
UrbanCode Deploy
UrbanCode Velocity
Planning (or ideation). In this workflow, teams scope out new features and
functionality in the next release, drawing from prioritized end-user feedback
and case studies, as well as inputs from all internal stakeholders. The goal in
the planning stage is to maximize the business value of the product by
producing a backlog of features that when delivered produce a desired
outcome that has value.
Development. This is the programming step, where developers test, code, and
build new and enhanced features, based on user stories and work items in the
backlog. A combination of practices such as test-driven development (TDD),
pair programming, and peer code reviews, among others are common.
Developers often use their local workstations to perform the “inner loop” of
writing and testing code before sending it down the continuous delivery
pipeline.
Integration (or build, or continuous Integration and continuous delivery
(CI/CD). As noted above, in this workflow the new code is integrated into the
existing code base, then tested and packaged into an executable for
deployment. Common automation activities include merging code changes
into a “master” copy, checking out that code from a source code repository,
and automating the compile, unit test and packaging into an executable. Best
practice is to store the output of the CI phase in a binary repository, for the
next phase.
Deployment (usually called continuous deployment). Here the runtime build
output (from integration) is deployed to a runtime environment - usually a
development environment where runtime tests are executed for quality,
compliance and security. If errors or defects are found, developers have a
chance to intercept and remediate any problems before any end users see
them. There are typically environments for development, test, and
production, with each environment requiring progressively “stricter” quality
gates. A good practice for deployment to a production environment is typically
to deploy first to a subset of end users, and then eventually to all users once
stability is established.
Operations. If getting features delivered to a production environment is
characterized as “Day 1”, then once features are running in production “Day
2” operations occur. Monitoring feature performance, behavior, and
availability ensures that the features are able to provide value add to end
users. Operations ensures that features are running smoothly and that there
are no interruptions in service - by making sure the network, storage,
platform, compute and security posture are all healthy! If something goes
wrong, operations ensures incidents are identified, the proper personnel are
alerted, problems are determined, and fixes are applied.
Learning (sometimes called continuous feedback). This is the gathering of
feedback from end users and customers on features, functionality,
performance and business value to take back to planning for enhancements
and features the next release. This would also include any learning and
backlog items from the operations activities, that could empower developers
to proactively avoid any past incidents that could happen again in the future.
This is the point where the “wraparound” to the Planning phase happens and
we “continuously improve!”
DevOps culture
It's generally accepted that DevOps methods can't work without a commitment to
DevOps culture, which can be summarized as a different organizational and technical
approach to software development.
In most cases the best way to accomplish this is to break down these silos and
reorganize them into cross-functional, autonomous DevOps teams that can work on
code projects from start to finish - planning to feedback - without making handoffs to,
or waiting for approvals from, other teams. When put in the context of agile
development, the shared accountability and collaboration are the bedrock of having a
shared product focus that has a valuable outcome.
In many ways, cloud-native development and DevOps are made for each other.
For example, developing and updating microservices - that is, the iterative delivery of
small units of code to a small code base - is a perfect fit for DevOps rapid release and
management cycles. And it would be difficult to deal with the complexity of a
microservices architecture without DevOps deployment and operation. A recent IBM
survey of developers and IT executives found that 78% of current microservices users
expect to increase the time, money and effort they’ve invested in the architecture, and
56% of non-users are likely to adopt microservices within the next two years.
Most leading cloud computing providers - including AWS, Google, Microsoft Azure,
and IBM Cloud - offer some sort of managed DevOps pipeline solution.
What is DevSecOps?
DevSecOps is DevOps that continuously integrates and automates security throughout
the DevOps lifecycle - from start to finish, from planning through feedback and back
to planning again.
Another way to put this is that DevSecOps is what DevOps was supposed to be from
the start. But two of the early significant (and for a time insurmountable) challenges
of DevOps adoption were integrating security expertise into cross-functional teams (a
cultural problem), and implementing security automation into the DevOps lifecycle (a
technical issue). Security came to be perceived as the "Team of 'No,'" and as an
expensive bottleneck in many DevOps practices.
The ultimate goal of SRE is similar to the goal of DevOps, but more specific: SRE
aims to balance an organization's desire for rapid application development with its
need to meet performance and availability levels specified in service level agreements
(SLAs) with customers and end-users.
A move toward greater automation should start with small, measurably successful
projects, which you can then scale and optimize for other processes and in other parts
of your organization.
See how you can place AI at the core of your entire IT operations toolchain
with IBM Cloud Pak for Watson AIOps.
Explore additional IBM tools to support a DevOps approach, including IBM
Architecture Room Live, IBM Rational Test Workbench, IBM UrbanCode
Deploy, and IBM UrbanCode Velocity.
Discover how IBM DevOps can help you shorten releases, improve reliability
and stay ahead of the competition.
Build DevOps skills through our “Introduction to DevOps for Cloud Solutions”
course contained within the Cloud Architect Professional learning curriculum
or the courses on DevOps capabilities and IBM Cloud Continuous Delivery
Toolchain contained within the Cloud Developer Professional learning
curriculum.
Register to download the Gartner report and discover how to future-proof
your IT operations with AI.
Download the IBM Cloud infographic that shows the benefits of AI-powered
automation for IT operations. (PDF, 467 KB)
Check out the eBook, Putting the Ops into DevOps for Dummies (PDF, 2.1 MB).
Read about the five “must-have’s” for automation success (link resides outside
IBM) in this HFS Research report.
Container Orchestration
Container orchestration automates and simplifies provisioning, and deployment and
management of containerized applications.
Featured products
The ability to create containers has existed for decades, but it became widely available
in 2008 when Linux included container functionality within its kernel, and widely
used with the arrival of the Docker open-source containerization platform in 2013.
(Docker is so popular that "Docker containers" and "containers" are often used
interchangeably.)
Because they are smaller, more resource-efficient and more portable than virtual
machines (VMs), containers - and more specifically,
containerized microservices or serverless functions - have become the de
facto compute units of modern cloud-native applications. (For more on the benefits of
containers see the interactive data visualization below)
In small numbers, containers are easy enough to deploy and manage manually. But in
most organizations the number of containerized applications is growing rapidly, and
managing them at scale - especially as part of a continuous integration/continuous
delivery (CI/CD) or DevOps pipeline - is impossible without automation.
Once the containers are deployed the orchestration tool manages the lifecycle of
the containerized application based on the container definition file (very often a
Dockerfile). This includes
It's probably clear that the chief benefit of container orchestration is automation - and
not only only because it reduces greatly the effort and complexity of managing a
large containerized application estate. By automating operations, orchestration
supports an agile or DevOps approach that allows teams to develop and deploy in
rapid, iterative cycles and release new features and capabilities faster.
Kubernetes
As noted above, Kubernetes is the most popular container orchestration platform.
Together with other tools in the container ecosystem, Kubernetes enables a company
to deliver a highly productive platform-as-a-service (PaaS) that addresses many of the
infrastructure- and operations-related tasks and issues around cloud-native application
development, so that development teams can focus exclusively on coding and
innovation.
Kubernetes’ advantages over other orchestration solutions are largely a result of its
more comprehensive and sophisticated functionality in several areas, including:
Cloud Databases
Cloud Databases
Learn more about data organization in the cloud.
Key features
A database service built and accessed through a cloud platform
Enables enterprise users to host databases without buying dedicated
hardware
Can be managed by the user or offered as a service and managed by a
provider
Can support SQL (including MySQL) or NoSQL databases
Accessed through a web interface or vendor-provided API
Benefits
Ease of access: Users can access cloud databases from virtually anywhere using a
vendor’s API or web interface.
Considerations
Control options: Users can opt for a virtual machine image managed like a
traditional database or a provider’s database as a service (DBaaS).
Database technology: SQL databases are difficult to scale but very common.
NoSQL databases scale more easily but do not work with some applications.
Security: Most cloud database providers encrypt data and provide other security
measures; organizations should research their options.
Maintenance: When using a virtual machine image, one should ensure that IT
staffers can maintain the underlying infrastructure.
The problem is that most databases require updates to occur in a central “master”
database. This can result in performance bottlenecks and also prevent applications
from running if the connection to the master database is unavailable.
A cloud database such as IBM Cloudant enables you to push database access to the
farthest edge of the network—such as mobile devices, remote facilities, sensors, and
Internet-enabled goods—so you can scale bigger and enable applications to continue
running while offline.
Hybrid databases create a distributed hybrid data cloud for increased performance,
reach, uptime, mobility, and cost savings:
This is the path to hybrid cloud that accommodates growing data management needs,
not infrastructure needs. Organizations can continuously optimize the data layer for
cost, performance, security, and reach. They can break up their data, distribute it, and
move it closer to their users.
For example, financial organizations are embracing the hybrid concept by using the
database as a central repository for all their disparate data sources and then delivering
this financial data in JSON format. This data is then distributed to the database as a
service and replicated to geographic regions across the world.
If a customer in Singapore has to wait more than four seconds for their mobile
application data to be retrieved from a database in New Jersey, that customer is not
likely to use that application again. Database-as-a-service can replicate and distribute
immediately and offer near real-time access to data worldwide.
Cloud databases can collect, deliver, replicate, and push to the edge all your data
using the new hybrid cloud concept. Users no longer have to deploy the dependent
middleware to deliver database requests anywhere in the world. They can connect
applications directly to their database.
Compared to traditional IT, cloud computing offers organizations a host of benefits: the cost-
effectiveness of paying for only the resources you use; faster time to market for mission-critical
applications and services; the ability to scale easily, affordably and — with the right cloud
provider — globally; and much more (see “What are the benefits of cloud computing?”
below). And many organizations are seeing additional benefits from combining public cloud
services purchased from a cloud services provider with private cloud infrastructure they operate
themselves to deliver sensitive applications or data to customers, partners and employees.
To read a full history of cloud computing, from mainframes to how virtualization introduced the
modern-day cloud, check out IBM’s history of cloud computing blog post.
With the right provider, cloud also offers the added benefit of greater choice and flexibility.
Specifically, a cloud provider that supports open standards and a hybrid multicloud
implementation (see “Multicloud and Hybrid Multicloud” below) gives you the choice and
flexibility to combine cloud and on-premises resources from unlimited vendors into a single,
optimized, seamlessly integrated infrastructure you can manage from a single point of control —
an infrastructure in which each workload runs in the best possible location based on its specific
performance, security, regulatory compliance and cost requirements.
Cloud services
IaaS – Infrastructure as a Service
With PaaS you can deploy web and mobile applications to the cloud in minutes, and innovate
faster and more cost-effectively in response to market opportunities and competitive threats.
PaaS is one of the fastest-growing cloud offerings today; Gartner forecasts the total market for
PaaS to exceed $34 billion by 2022 (link resides outside IBM), doubling its 2018 size.
Serverless Computing
Serverless offloads all responsibility for infrastructure management tasks (scaling, scheduling,
patching, provisioning) to the cloud provider, allowing developers to focus all their time and
energy on code.
Serverless runs code only on demand — that is, when requested by the application, enabling the
cloud customer to pay for compute resources only when they code is running. With serverless,
you never pay for idle computing capacity.
To learn more about serverless — including which workloads are prime targets for serverless,
and which are not — read this post.
SaaS is application software that runs in the cloud, and which customers use via internet
connection, usually in a web browser, typically for a monthly or annual fee. SaaS is still the most
widely used form of cloud computing. If you’ve used salesforce.com, Hubspot or Carbonite,
you’ve used SaaS.
SaaS lets you and your team start using software rapidly. Just sign up and get to work. It lets you
access your specific instance of the application and your data from any computer, and typically
from any mobile device. If your computer or mobile device breaks, you don’t lose your data
(because it’s all in the cloud). The software scales as needed. And the SaaS vendor applies fixes
and updates without any effort on your part.
Public cloud
Private cloud
Hybrid cloud
Multicloud
IBM Cloud
Public cloud
In a public cloud, a cloud provider offers affordable access to cloud services, running on some
portion of its privately-owned infrastructure, via the internet. Customers don’t need to purchase
any hardware, software or supporting infrastructure of their own; everything is owned and
managed by the cloud provider, and the customer effectively “rents” a portion of it for a
subscription or usage-based fee. Multiple customers — thousands and thousands — share the
resources of a public cloud.
Public cloud offers instant access to SaaS business applications, IaaS computing and storage
resources, and PaaS for application deployment and development. According to
Gartner, customers will spend $266.4 billion on public cloud services this year (link resides
outside IBM), up 17% from last year.
Private cloud
Private cloud is cloud infrastructure operated exclusively for one company; it’s managed by the
company or a third party (or both), and is hosted primarily on premises, but can also be hosted on
dedicated cloud-provider or third-party infrastructure. Private cloud enables a company to take
advantage of cloud efficiencies while providing greater control over resources, data security and
regulatory compliance, and avoiding the potential impact of sharing resources with another cloud
customer (called “shared tenancy”).
Hybrid cloud
Hybrid cloud integrates private and public clouds, using technologies and management tools that
allow workloads to move seamlessly between both as needed for optimal performance, security,
compliance and cost-effectiveness. For example, hybrid cloud enables a company to keep
sensitive data and mission-critical legacy applications (which can’t easily be migrated to the
cloud) on premises, while leveraging public cloud for SaaS applications, PaaS for rapid
deployment of new applications, and IaaS for additional storage or compute capacity on demand.
Learn more about hybrid cloud
Increasingly, businesses are embracing hybrid multicloud as the deployment model that lets them
take maximum advantage of cloud agility and flexibility; meet their security and regulatory
compliance needs; and integrate their legacy applications and systems. According to industry
analyst 451 Research (Video, 02:03), at least 67% of businesses use two or more separate clouds,
and 55% or organizations have settled on a hybrid multicloud approach. IBM estimates hybrid
cloud to be a $1.2-trillion business opportunity for cloud and cloud service providers.
IBM Cloud maintains 60 data centers worldwide, enabling local deployment, global scalability,
and built-in resiliency and redundancy on six continents. 47 of the Fortune 50 companies trust
mission-critical applications to IBM Cloud’s enterprise-grade infrastructure. And IBM is the one
cloud provider that’s also a leading IT security organization, with over 8,000 security experts on
staff.
Learn how American Airlines became more responsive to customer needs with a new technology
platform from the IBM Cloud.
To get started with IBM Cloud, sign up for an IBMid and create your IBM Cloud account.
Common convention points to public cloud as the delivery model of choice. But, when
considering the right architecture of cloud computing for your applications and workloads, you
must begin by addressing the unique needs of your business.
This can include many factors, such as government regulations, security, performance, data
residency, service levels, time to market, architecture complexity, skills and preventing vendor
lock-in. Add in the need to incorporate the emerging technologies, and you can see why IT
leaders are challenging the notion that cloud computing migration is easy.
At first glance, the types of cloud computing seem simple: public, private or a hybrid mix of
both. In reality, the choices are many. Public cloud can include shared, dedicated and bare metal
delivery models. Fully and partially managed clouds are also options. And, in some cases,
especially for existing applications where architectures are too complex to move or the cost-
benefit ratio is not optimal, cloud may not be the right choice.
The right model depends on your workload. You should understand the advantages and
disadvantages of each cloud deployment model and take a methodical approach to determining
which workloads to move to which type of cloud for the maximum benefit.
Dive deeper into specific cloud service and deployment models, cloud computing architecture
and cloud computing examples
The other major benefit of storage software is that it can access and analyze any kind of data
wherever it lives, no matter the hardware, platform or format. So, from mobile devices linked to
your bank to servers full of unstructured social media information, data can be understood via the
cloud.
Cloud service providers have no shared standard “units” for cloud capacity or common pricing
structures, nor are there common specifications for the underlying hardware that runs the cloud
applications. As a result, an assumption of total workload cost based on a provider’s basic “per
unit” rate can easily be off by orders of magnitude.
Use the cloud pricing calculator to get an idea of your workload costs
As the foundation of information security, a hardware-rooted chain of trust verifies the integrity
of every relevant component in the cloud platform, giving you security automation that flexibly
integrates into the DevOps pipeline. A true chain of trust would start in the host chip
firmware and build up through the container engine and orchestration system, securing all critical
data and workloads during an application’s lifecycle.
Hardware is the ideal foundation because it is rooted in silicon, making it difficult for hackers to
alter.
The chain of trust would be built from this root using the measure-and-verify security model,
with each component measuring, verifying and launching the next level. This process would
extend to the container engine, creating a trust boundary, with measurements stored in a Trusted
Platform Module (TPM) on the host.
So far, so good—but now you must extend this process beyond the host trust boundary to the
container orchestration level. You must continue to scale security.
Attestation software on a different server can verify current measurements against known good
values. The container orchestrator communicates with the attestation server to verify the integrity
of worker hosts, which in turn setup and manage the containers deployed on
them. All communication beyond the host trust boundary is encrypted, resulting in a highly
automated, trusted container system.
The chain of trust architecture is designed to meet the urgent need for both security and rapid
innovation. Security officers can formulate security policies that are automatically applied to
every container being created or moved. Beyond maintaining the policies themselves in a
manifest, each step in the sequence is automated, enabling DevOps teams to quickly build and
deploy applications without manually managing security.
As your team evaluates cloud platforms, ask vendors to explain how they establish and
maintain trust in the technology that will host your organization’s applications. It helps to have
clear expectations going in.
What is virtualization?
Virtualization is a process that allows for more efficient utilization of physical
computer hardware and is the foundation of cloud computing.
For a further overview of how virtualization works, see our video “Virtualization
Explained”:
Featured products
Benefits of virtualization
Virtualization brings several benefits to data center operators and service providers:
For a more in-depth look at the potential benefits, see "5 Benefits of Virtualization."
Solutions
Several companies offer virtualization solutions covering specific data center tasks or
end user-focused, desktop virtualization scenarios. Better-known examples include
VMware, which specializes in server, desktop, network, and storage virtualization;
Citrix, which has a niche in application virtualization but also offers server
virtualization and virtual desktop solutions; and Microsoft, whose Hyper-V
virtualization solution ships with Windows and focuses on virtual versions of server
and desktop computers.
Types of virtualization
To this point we’ve discussed server virtualization, but many other IT infrastructure
elements can be virtualized to deliver significant advantages to IT managers (in
particular) and the enterprise as a whole. In this section, we'll cover the following
types of virtualization:
Desktop virtualization
Network virtualization
Storage virtualization
Data virtualization
Application virtualization
Data center virtualization
CPU virtualization
GPU virtualization
Linux virtualization
Cloud virtualization
Desktop virtualization
Desktop virtualization lets you run multiple desktop operating systems, each in its
own VM on the same computer.
Network virtualization
Storage virtualization
Data virtualization
Modern enterprises store data from multiple applications, using multiple file formats,
in multiple locations, ranging from the cloud to on-premise hardware and software
systems. Data virtualization lets any application access all of that data—irrespective
of source, format, or location.
Data virtualization tools create a software layer between the applications accessing the
data and the systems storing it. The layer translates an application’s data request or
query as needed and returns results that can span multiple systems. Data virtualization
can help break down data silos when other types of integration aren’t feasible,
desirable, or affordable.
Application virtualization
Data center virtualization abstracts most of a data center’s hardware into software,
effectively enabling an administrator to divide a single physical data center into
multiple virtual data centers for different clients.
Each client can access its own infrastructure as a service (IaaS), which would run on
the same underlying physical hardware. Virtual data centers offer an easy on-ramp
into cloud-based computing, letting a company quickly set up a complete data center
environment without purchasing infrastructure hardware.
CPU virtualization
CPU (central processing unit) virtualization is the fundamental technology that makes
hypervisors, virtual machines, and operating systems possible. It allows a single CPU
to be divided into multiple virtual CPUs for use by multiple VMs.
GPU virtualization
Linux virtualization
Linux includes its own hypervisor, called the kernel-based virtual machine (KVM),
which supports Intel and AMD’s virtualization processor extensions so you can create
x86-based VMs from within a Linux host OS.
As an open source OS, Linux is highly customizable. You can create VMs running
versions of Linux tailored for specific workloads or security-hardened versions for
more sensitive applications.
Cloud virtualization
If you’d like to learn more about these cloud service models, see our guide: “IaaS vs.
PaaS vs. SaaS.”
For a deep dive into containers and containerization, check out “Containers: A
Complete Guide” and “Containerization: A Complete Guide.”
Check out the blog post "Containers vs. VMs: What's the difference?" for a closer
comparision.
In the following video, Sai Vennam breaks down the basics of containerization and
how it compares to virtualization via VMs:
VMware
VMware creates virtualization software. VMware began by offering server
virtualization only—its ESX (now ESXi) hypervisor was one of the earliest
commercially successful virtualization products. Today VMware also offers solutions
for network, storage, and desktop virtualization.
For a deep dive on everything involving VMware, see “VMware: A Complete Guide.”
Security
Virtualization offers some security benefits. For example, VMs infected with malware
can be rolled back to a point in time (called a snapshot) when the VM was uninfected
and stable; they can also be more easily deleted and recreated. You can’t always
disinfect a non-virtualized OS, because malware is often deeply integrated into the
core components of the OS, persisting beyond system rollbacks.
The market offers a range of virtualization security products that can scan and patch
VMs for malware, encrypt entire VM virtual disks, and control and audit VM access.
Modernize your applications for interoperability and ROI Enhance the value of your existing
apps and reduce the cost to maintain them.
Learn more
Microservices in the enterprise, 2021 New IBM research reveals the benefits and challenges of
microservices adoption.
Benefits of PaaS
The most commonly-cited benefits of PaaS, compared to an on-premises platform, include:
Faster time to market. With PaaS, there’s no need to purchase and install the hardware
and software you use to build and maintain your application development platform—and
no need for development teams to wait while you do this. You simply tap into the cloud
service provider’s PaaS to begin provisioning resources and developing immediately.
Affordable access to a wider variety of resources. PaaS platforms typically offer
access to a wider range of choices up and down the application stack—
including operating systems, middleware, databases and development tools—than most
organizations can practically or affordably maintain themselves.
More freedom to experiment, with less risk. PaaS also lets you try or test
new operating systems, languages and other tools without having to make substantial
investments in them, or in the infrastructure required to run them.
Easy, cost-effective scalability. With an on-premises platform, scaling is always
expensive, often wasteful and sometimes inadequate: You have to purchase
additional compute, storage and networking capacity in anticipation of traffic spikes;
much of that capacity sits idle during low-traffic periods, and none of it can be increased
in time to accommodate unanticipated surges. With PaaS, you can purchase additional
capacity, and start using it immediately, whenever you need it.
Greater flexibility for development teams. PaaS services provide a
shared software development environment that allows development and operations teams
access to all the tools they need, from any location with an internet connection.
Lower costs overall. Clearly PaaS reduces costs by enabling an organization to avoid
capital equipment expense associated with building and scaling an application platform.
But PaaS also can also reduce or eliminate software licensing costs. And by handling
patches, updates and other administrative tasks, PaaS can reduce your overall application
management costs.
Featured products
Related links
SaaS is application software you use via the cloud, as if it were installed on your computer (in
some cases, parts of it are installed on your computer). SaaS enables your organization to use an
application without the expense of setting up the infrastructure to run it, and the effort and
personnel to maintain it (apply bug fixes and updates, address outages, etc.) Salesforce and Slack
are examples of popular SaaS offerings; most web applications are considered SaaS.
IBM Cloud Pak for Applications helps you modernize existing applications, embed additional
security, and develop new apps that unleash digital initiatives. It offers cloud-native development
solutions that can quickly deliver value, along with flexible licensing that can be tailored to your
specific needs.
Cloud native refers less to where an application resides and more to how it is built and deployed.
In the video, "What is Cloud Native?", Andrea Crawford gives an overview of some of the key
concepts:
Microservices in the enterprise, 2021 - New IBM research reveals the benefits and challenges of
microservices adoption.
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 recent IBM survey of over IT executives, developer executives and developers, 87% of
microservices users agreed that microservices adoption is worth the expense and effort.
Learn more about why you should use microservices and containers as an architectural construct.
Modernize your applications for interoperability and ROI - Enhance the value of your existing apps and
reduce the cost to maintain them.
Learn more
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
Featured products
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.
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.
Development principles
Whether creating a new cloud native application or modernizing an existing application,
developers adhere to a consistent set of principles:
Storage
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.
Discover how IBM Cloud Object Storage creates a persistent data store for cloud native
applications.
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.
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 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.
See how you can start to move forward by using IBM for cloud native.
Learn how IBM can help lead the way with cloud native professional services.
Try your hand at modernizing an existing app for cloud native deployment with this tutorial.
Explore the Cloud Native and Multicloud course and badge contained within the IBM Cloud
Associate Solution Advisor role-based certification.
Build skills through modern integration, security, and identity courses, such as “Deploying Cloud-
Native Architectures and Applications” and “Preparing for Cloud-Native Security” contained
within the IBM Cloud Professional Developer role-based training and certification.
Get started with an IBM Cloud account today.
What is Kubernetes?
Kubernetes is developed by the community with the intent of addressing
container scalability and management needs. In the early days of Kubernetes, the community
contributors leveraged their knowledge of creating and running internal tools, such as Borg and
Omega. With the advent of the Cloud Native Computing Foundation (CNCF) in partnership with
the Linux Foundation, the community adopted Open Governance for Kubernetes. IBM, as a
founding member of CNCF, actively contributes to CNCF’s cloud-native projects, along with
other companies like Google, Red Hat, Microsoft, and Amazon.
Pros of Kubernetes
What is Docker Swarm?
Docker Swarm is another open-source container orchestration platform that has been around for
a while. Swarm —or more accurately, swarm mode — is Docker’s native support for
orchestrating clusters of Docker engines. A Swarm cluster consists of Docker
Engine deployed Swarm manager nodes (which orchestrate and manage the cluster) and worker
nodes (which are directed to execute tasks by the manager nodes).
Built for use with the Docker Engine (Docker is a container platform used for building and
deploying containerized applications)
Has its own Swarm API
Smoothly integrates with Docker tools like Docker Compose and Docker CLI (uses the
same command line interface (CLI) as Docker Engine)
Tools, services, and software that run with Docker containers will also work well with Swarm
Is easy to install and set up for Docker environments
Uses a filtering and scheduling system to provide intelligent node selection, allowing you to pick
the optimal nodes in a cluster for container deployment
Cons of Docker Swarm
Not to confuse matters too much, but Docker Enterprise Edition now supports Kubernetes too.
Docker Swarm vs. Kubernetes: A simple head-to-head
comparison
Installation and setup
Now that you’ve covered the differences between Kubernetes and Docker Swarm, take a deeper
dive in the IBM Cloud Kubernetes Service and learn how to build a scalable web application
on Kubernetes.
What is Istio?
Learn more about Istio—open technology that provides a way for developers to
seamlessly connect, manage, and secure networks of different microservices.
Istio is a configurable, open source service-mesh layer that connects, monitors, and
secures the containers in a Kubernetes cluster. At this writing, Istio works natively
with Kubernetes only, but its open source nature makes it possible for anyone to write
extensions enabling Istio to run on any cluster software. Today, we'll focus on using
Istio with Kubernetes, its most popular use case.
Because it is open source, Istio can run on any public cloud provider that supports it
and any private cloud with willing administrators.
Containers in the enterprise - New IBM research documents the surging momentum of
container and Kubernetes adoption.
The most common way to do this in a cluster is to use the sidecar pattern. A sidecar is
a new container, inside the pod, that routes and observes communications traffic
between services and containers.
Flexible, resilient, secure IT for your Hybrid Cloud - Containers, Kubernetes and Istio
are part of an open hybrid cloud strategy lets you build and manage workloads from
anywhere.
Learn more
Configuration
The primary method to set configuration with Kubernetes is the kubectl command,
commonly "kubectl -f <filename>", where the file is a YAML file. Istio users can
either run new and different types of YAML files with kubectl or use the new,
optional, ioctl command.
Monitoring
With Istio, you can easily monitor the health of your applications running with
Kubernetes. Istio's instrumentation can manage and visualize the health of
applications, providing more insight than just the general monitoring of cluster and
nodes that Kubernetes provides.
Management
Because the interface for Istio is essentially the same as Kubernetes, managing it takes
almost no additional work. In fact, Istio allows the user to create policies that impact
and manage the entire Kubernetes cluster, reducing time to manage each cluster while
eliminating the need for custom management code.
Featured products
Benefits
The major benefits of a service mesh include capabilities for improved debugging,
monitoring, routing, security, and leverage. That is, with Istio, it will take less effort to
manage a wider group of services.
Improved debugging
Say, for example, that a service has multiple dependencies. The pay_claim service at
an insurance company calls the deductible_amt service, which calls the
is_member_covered service, and so on. A complex dependency chain might have 10
or 12 service calls. When one of those 12 is failing, there will be a cascading set of
failures that result in some sort of 500 error, 400 error, or possibly no response at all.
To debug that set of calls, you can use something like a stack trace. On the frontend,
client-side developers can see what elements are pulled back from web servers, in
what order, and examine them. Frontend programmers can get a waterfall diagram to
aid in debugging.
What the example does not show is what happens inside the data center—how
callback=parselLotamaAudiences calls four other web services and which ones
respond more slowly. Later, we will see how Istio provides tools to trace function
calls in a diagram much like this one.
Policy
By default, Kubernetes allows every pod to send traffic to every other pod. Istio
allows administrators to create a policy to restrict which services can work with each
other. So, for example, services can only call other services that are true
dependencies. Another policy to keep services up is a rate limit, which will stop
excess traffic from clogging a service and prevent denial of service attacks.
By default, Kubernetes provides round-robin load balancing. If there are six pods that
provide a microservice, Kubernetes will provide a load balancer, or "service," that
sends requests to each pod in increasing order, then it will start over. However,
sometimes a company will deploy different versions of the same service in
production.
The simplest example of this may be a blue/green deploy. In that case, the software
might build an entirely new version of the application in production without sending
production users to it. After promoting the new version, the company can keep the old
servers around to make switchback quick in the event of failure.
Circuit breaking
Security
Istio provides identity, policy, and encryption by default, along with authentication,
authorization, and audit (AAA). Any pods under management that communicate with
others will use encrypted traffic, preventing any observation. The identity service,
combined with encryption, ensures that no unauthorized user can fake—or "spoof"—a
service call. AAA provides security and operations professionals the tools they need
to monitor, with less overhead.
Simplified administration
Traditional applications still need the identify, policy, and security features that Istio
offers. That has programmers and administrators working at the wrong level of
abstraction, reimplementing the same security rules over and over for every service.
Istio allows them to work at the right level—setting policy for the cluster through a
single control panel. At the same time, with Istio's access controls, dashboards, and
debugging tools described below, you can easily add a plugin at the command line,
rather than go to a web page.
Examples
Visualize services
Istio 1.1 includes a new add-on called Kiali that which provides a web-based
visualization. You can use it to track service requests, drill into details, or even export
the service request history as a JSON to query and format in your own way. The
workload graph below offers a real-time generated dependency graph based on the
services that actually depend on each other. It is generated from actual observations of
traffic.
The Jaeger service, a component of Istio, provides tracing for any given service. In
this example, we’ve traced the product page. Ever dot in the first image represents a
service call. By clicking on a dot, we can “drill down” into the waterfall diagram to
follow the exact services requests and responses.
We can also look more closely at the product page. We can see the errors are in
product page itself—that details returned successfully.
Dashboards
Istio comes with many dashboards (out of the box) to monitor system health and
performance. These can measure CPU and memory utilization, traffic demand, the
number of 400 and 500 errors, time to serve requests, and more. Best of all, they are
available by simply installing and running Istio and adding Grafana, one of the
included open source dashboard tools for Istio. Istio also provides two other
dashboards: Kiali and Jaeger.
Istio Tutorials
The Istio website (link resides outside IBM) includes lots of helpful documentation
and instructions for getting started with Istio.
Planning
Plan and manage all resources required to meet customer demand for a company’s
product or service. When the supply chain is established, determine metrics to
measure whether the supply chain is efficient, effective, delivers value to customers
and meets company goals.
Sourcing
Choose suppliers to provide the goods and services needed to create the product.
Then, establish processes to monitor and manage supplier relationships. Key
processes include: ordering, receiving, managing inventory and authorizing supplier
payments.
Manufacturing
Organize the activities required to accept raw materials, manufacture the product, test
for quality, package for shipping and schedule for delivery.
Returning
IDC’s Simon Ellis in The Path to a Thinking Supply Chain² defines what is supply
chain management by identifying the five “Cs” of the effective supply chain
management of the future:
Cyber-aware: The supply chain must harden its systems and protect them
from cyber-intrusions and hacks, which should be an enterprise-wide concern.
As recently as 2017, a typical supply chain accessed 50 times more data than just five
years earlier.¹ However, less than a quarter of this data is being analyzed. That means
the value of critical, time-sensitive data — such as information about weather, sudden
labor shortages, political unrest and microbursts in demand — can be lost.
Modern supply chains take advantage of massive amounts of data generated by the
chain process and are curated by analytical experts and data scientists. Future supply
chain leaders and the Enterprise Resource Planning (ERP) systems they manage will
likely focus on optimizing the usefulness of this data — analyzing it in real time with
minimal latency.
Continuous deployment offers several benefits for enterprises looking to scale their
applications and IT portfolio. First, it speeds time to market by eliminating the lag
between coding and customer value—typically days, weeks, or even months.
While “continuous deployment” and “continuous delivery” may sound like the same
thing, they are actually two different approaches to frequent release.
Continuous deployment takes automation a step further and removes the need for
manual intervention. The tests and developers are considered trustworthy enough that
an approval for production release is not required. If the tests pass, the new code is
considered to be approved, and the deployment to production just happens.
Typically, when working on the same software development project, developers work
off of individual copies of a master branch of code. However, functionality issues and
bugs can occur after developers merge their changes onto the main codebase,
especially when developers work independently from each other. The longer they
work independently, the higher the risk.
With CI, everyone merges their code changes into a repository at least once per day.
As updates occur, automated build tests run to ensure that any changes remain
compatible with the master branch. This acts as a fail-safe to catch integration
problems as quickly as possible.
For a closer look at how continuous integration differs from continuous delivery and
continuous deployment, see the blog post “Continuous integration vs. continuous
delivery: A quick explainer” and the video "What is Continuous Integration?":
Here are some of the most crucial tools used in a continuous deployment workflow:
Multicloud deployments
Using UrbanCode Deploy’s Easy Process and Blueprint Designer, organizations can
create custom cloud environment models to visualize how their applications should be
deployed to public, private, and hybrid cloud. Blueprint Designer allows users to
create, update, and break down full-stack computing environments while enabling full
cloud orchestration capabilities. All environments can then be provisioned to deploy
application components automatically or on demand.
Distributed automation
While UrbanCode Deploy supports the use of your own scripts, out-of-the-box
plugins make deployment processes easier to design and manage. By using tested
integrations, developers can utilize pre-built automation that has already been proven.
This replaces the need to create custom scripts specifically for UrbanCode Deploy.
To learn more about IBM UrbanCode Deploy and how it can evolve your deployment
process, explore IBM’s deployment automation solution.