There is cloud computing used in most businesses regardless of size. Eighty-four percent of organizations in the Philippines use cloud services in some capacity, as studied by the Asia Cloud Computing Association.
The Southeast Asia public cloud services market, meanwhile, is projected to grow at an annual compounded growth rate of 22.7% and is expected to reach $40.32 billion by 2025, according to MarketsandMarkets’ research.
The cloud industry has advanced from the more basic Cloud era to what is now called: Cloud Native.
There is no standardized definition of what Cloud Native really means, but the main essence is this: optimizing business applications to take full advantage of the distributed benefits of cloud computing.
This definition may address the potential but the question now becomes: “How can Cloud Native offerings help my company succeed, what are the trivial options, and what impact will this technology have on my business goals?”.
Trying to answer those questions is what we will be discussing in this article.
Most growing businesses face constant pressure to make digital drivers like data, applications, and infrastructure be more “nimble.”
Cloud Native approach is appropriate for use-cases where your organization would like the application software to be “born in the cloud”.
These three advantages are what stands out to me based on experience:
(1) Release Agility: Cloud-native practice enables rapid and automated testing and deployment of changes. This streamlines the release cycle process, minimizing human errors and manual efforts.
(2) Elastic Scalability: Applications can take full advantage of cloud providers’ elastic scaling capabilities, resources can automatically scale up or down based on demand. Enabling organizations to cope with spikes in customer traffic, ensuring optimal use of resources during low periods and availability during peak periods.
(3) Ease of management: Cloud Native tools have incorporated monitoring and observability tools that provide real-time insights into applications’ health. It has proactive alerting and basic troubleshooting of components that can help identify and address issues before they impact customers. It’s intentional to leave out Cost and Security as Cloud Native benefits because saying they are is subjective and also depend on the model being compared to.
From Monoliths to Microservices
Data regulatory remains to be the top hindrance to cloud adoption, but these conservative sectors are transitioning decently.
Fifty-four of financial industry respondents to McKinsey’s survey said they expect more than half of their workloads to be on public cloud in five years.
Domain-level migration (i.e. noncritical business unit as guinea pig), partnering with Cloud Service Providers (CSPs), and creating a digital business unit or subsidiary are some of the strategies to lower barriers to entry.
Hybrid multi-cloud architectures and the rise of sovereign cloud are equally viable options for the public sector, healthcare, and financial businesses to ease their way in.
The current data center boom in the Philippines is a testament that developing countries are the next hyperscaler hub. Some of these data centers are hyperconverged infrastructure compatible and have an option in their offering to Direct Connect with hyperscalers to alleviate security and latency concerns.
Commercial-off-the-shelf (COTS) applications running On-Premise still process and manage some of the most mission-critical data in our lives.
Legacy COTS are Monolithic applications that reliably work, and do specialized computing requirements well — they don’t always need modernizing if there’s no business case to do so.
Instead, we can integrate with them in some way, such as through APIs, to abstract the complexities. A monolithic application is built and maintained as a singular executable software, which then creates data silos as a major downside.
They can be highly complex systems that are hard to maintain and scale, running on aging platforms and use outdated architectures that aren’t compatible for the cloud — some can with considerable tweaks.
This type of application is not considered cloud native. Enter: Microservices architecture. As businesses face a growing demand for enhanced customer experiences, faster time to market, and increased operational efficiency. The more it makes sense for IT decision-makers to look at Cloud Native’s Microservices for agility.
Microservice applications composed of smaller, self-sustaining services that can be developed, deployed, and scaled independently.
The ‘modular’ approach enables the possibility of scaling specific services on demand, rather than scaling the entire system.
Microservices architecture enhances fault isolation, meaning that if a specific microservice fails, it doesn’t bring down the entire system.
This isolation provides resilience and fault tolerance, as failures in one microservice are less likely to impact other services. This extends to resolving and troubleshooting software issues, as issues can be isolated to a single service.
The recommended way to modernize a monolith to Cloud Native is to migrate/rewrite it into smaller microservices that are much easier to manage, update, horizontally scale, and maintain.
The scope of right-sizing ‘how small a microservice should be’ is highly debatable due to the underlying inter-dependency of a service use case both functionally and technically.
There are several Cloud Native options that I will try to explain in the following sections; which one best suits your needs is highly dependent on the business problem being solved, your organization’s cloud maturity, and strategic roadmap in technology.
Serverless vs. Containers
Even in most cloud-based models, you need to manage cloud servers, operating systems, and other components to deploy and run applications.
Serverless computing, also known as Function as a Service (FaaS), is a Cloud Native option where you can build and run applications without the worries of managing the underlying computing or server infrastructure.
The hyperscaler or cloud native provider takes care of provisioning, scaling, and managing the servers, allowing you to focus on just building the necessary service functionality.
The most fitting type of software for Serverless is Event-Driven Execution, Serverless functions will be executed in response to specific events or triggers, such as HTTP requests, database updates, file uploads, or scheduled tasks.
Serverless functions are stateless by design, they do not maintain a persistent (data storage) state between invocations.
Any required data or context needs to be provided with each function invocation or called by the function to externally retrieve the data.
The pricing for serverless is based on the number of requests made to that application function and the computing resources used in the process.
This model can potentially be more cost-effective than other models, as the user only pays for the resources used during the execution of that specific function.
Containers refer to the use of containerization technology within cloud computing environments. Containers are portable, and isolated units that package an application and its dependencies, providing a consistent and portable way of running the application across different cloud environments.
Containers encapsulate the application and its dependencies, ensuring that it operates independently and consistently regardless of the underlying infrastructure.
In containerization, Kubernetes and Docker are two open standards that organizations leverage to manage and deploy containers across a cluster of virtual machines in the cloud without worrying about individual operating systems.
This Cloud Native option simplifies the management and operation of your applications due to its immutable infrastructure nature, tasks such as scaling, load balancing, and networking are seamlessly embedded.
In summary, serverless computing is best for event-driven workloads, offers automatic scaling, with very minimal operational and cloud management overhead.
However, there are applications that are business critical and containers provide optimum cloud management control with the advantage of portability, making containers ideal for consistent deployments across different cloud environments.
Best-of-breed vs All-in-one
Shifting the discussion on the prevailing dilemma of IT decision-makers when embarking on complex cloud & digital programs.
Will you opt for the best-of-breed option (i.e. multi-cloud, CI/CD stack) or the – what you thought is the – lesser headache of going to a single solution/vendor route?
An enterprise’s technology stack is ideally future-proofed, standardized, and uses a low-code application development approach.
However, it doesn’t make it easy for organizations that an increasing number of solutions claim to be one of the top that check all of these boxes.
Similar to my monolithic application views, I do not dislike the all-in-one or single vendor option – as it just makes things easier.
The three advantages are:
(1) Procurement Process: Not many enjoy the necessary evil of comparing cloud solutions for every new application and the timeline it takes for every purchase; might as well stick-to-one to exert more energy in actually delivering.
(2) With the old saying of “One Throat to Choke”, the responsible software provider will take accountability in case something goes wrong on their end, there’s just one company to blame.
(3) Simplified Management: An all-in-one offers consolidation and integrated solutions (well, most of the time).
Business users and customers have a unified interface, data repository, billing, and management for the plethora of cloud & digital services, reducing administrative and staffing overhead.
However, the close relationship (partnership) and the high dependency to the vendor borders decade-long vendor lock-in where migrating out is cost and labor intensive.
What I’ve noticed with single vendor solutions is that they tend to be inferior in one or two modules, and there’s an excessive amount of included features/modules that either complicate the stack or are never used (pitched as add-on or nice-to-have just in case).
This is where the best-of-breed option is strong, the idea is having the best-in-class solution for each cloud technology domain, businesses can leverage the specialized expertise and advanced functionalities on an area the provider is strongest.
Best-of-breed solutions, with their narrow focus, typically keep up with the development of advanced solution features that may serve as the differentiator you’re looking for in your product modeling facelift.
In terms of cloud native infrastructure, best-of-breed provides worst-case resiliency, whether it is an attack or a submarine cable outage; with multi-cloud, the damage to a business can be minimized. Additionally, a diversified and layered software stack minimizes security risks.
In summary, the best-of-breed option allows you to isolate and tune each component of the technology stack, while the all-in-one vendor strategy offers convenience, integration advantages, and potentially cost savings through bundled add-ons.
Reconsider your objectives to find specific needs, like the complexity level of customizations, how important integration is, what type of scalability is acceptable (horizontal or vertical), and your risk appetite on vendor lock-in.
Ultimately, weigh what’s more important between having specialized services & applications, versus the benefits of simplicity and an integrated ecosystem.
A tool is only as good as the hands that wield it
Finding the best Cloud Native fit is not only about business needs, pains and objectives, but also your current IT skills & capability gaps and how important stability and control are — for example, is it critical to pursue containerization now, or is it acceptable to begin with functions combined with a SaaS-hosted best-of-breed approach at some point?
Leverage the procurement process every step of the way in your roadmap, and the key points to consider are:
(1) Evaluate each solution for its fit to functional and nonfunctional requirements, focusing on the immediate while considering the flexibility of future investments.
(2) Create a succinct evaluation mechanism (minimum viable product demo) that allows you to objectively compare each solution without relying heavily on the vendor’s RFP response, pitch, and slides to come up with your own scoring.
(3) Create a lean multidisciplinary team with key stakeholders to allow different perspectives and to consider re-imagining the organization’s product possibilities, avoiding the trap of lift-and-shift of what you already have while diluting the solution’s value proposition potential.
Finally, before pulling the trigger, come up with your own answers to the following questions:
- Is my IT and business capability ready for this solution?
- Does the solution support open standards of the industry?
- Is the Data Model properly structured and is the design compatible with my product portfolio?
- How seamless or complex will it be for this solution to integrate with other systems?
- Will the solution work within a best-of-breed environment and be able to run on what flavors of cloud environment?
- Does this solution have the functionalities needed to support my roadmap and operational plans?
- Is the historical solution improvements fast enough to keep up with the changing trends, and is the future roadmap aligned with the portfolio I have in mind?
The author is a managing consulting director of Capgemini Philippines
