Boost the adoption of Cloud by maximizing the benefits from the Cloud in an efficient and enterprise-ready way from the build to the run phases.
Cloud Adoption
readme
Enterprises are adopting the Cloud for various reasons, from emptying the local datacentre for cost savings to staying ahead of the market with flexible Cloud resources. For each Cloud adoption flavour, there is a trade-off between the cost of Cloud adoption and the Cloud benefits the enterprise gets as a result.
Cloud adoption by moving workloads in a lift & shift way to the Cloud comes with low costs but also minimal Cloud benefits. While on the other end, building a completely new Cloud system based on the latest Cloud architecture practices will cost significantly more but also bring more benefits needed by the modern business.
| Re-host | Lift and Shift workloads as-is to the Cloud. |
| Refactor | Redeploy workloads on the Cloud by using the automation capabilities of the Cloud, without code changes at the application level. |
| Revise | Optimize the run and lifecycle of a system by decoupling components and choosing the best Cloud resource for it, applying the required code changes at the application level. |
| Rebuild | Redraw the systems architecture for cloud while rebuilding and reusing application components. |
| New | Start from scratch with a shiny new system (application) adhering to the current architecture best practices. |
Most often Cloud adoption starts with migrating existing workloads (via revise or refactor) and/or experimenting with new workloads. Both adoption paths come with challenges.
- Companies adopting the cloud without application code change via re-hosting can experience that their innovation speed doesn’t follow the speed of the market. While the business goal could be to transform the legacy at the speed of Cloud, this is purely a one-off cost optimization project.
- Companies adopting the cloud without application code change via refactor are looking for better leverage of cloud benefits (cost and agility), knowing that they will have to manage application changes at the speed of the market.
- On the other side, companies adopting via new or rebuild can see an enormous workload of hundreds (tens) of services to be built in a consistent way via Cloud native architectures.
Focus Areas
Getting the maximum business benefit from Cloud adoption requires much more than simply moving workloads to new cloud resources. There should be a focus on three specific areas.
- Platform and its capabilities.
- People, process and how they work together.
- The system architecture and how components can be updated individually.
Platform
Cloud platforms offer many ways to implement and support business functionality. This business support is the ultimate goal and therefore is the primary deciding factor in how guidelines and rules apply to the implementation choices of cloud solutions.
Business support needs of systems are described in functionality and quality attributes. Both influence the selection decisions for cloud platforms, services, and implementations.
There are many quality attributes for systems. The selection of attributes and the severity of each vary from system to system. This is a common list of quality attributes:
- Availability
- Scalability
- Agility
- Interoperability
- Maintainability
- Manageability
- Performance
- Reliability
- Security
- Modifiability
- Testability
- Deploy-ability
- Recoverability
- Portability
- Billability (Pay per efficiency)
Per cloud platform category (IaaS, PaaS, SaaS) the support for these quality attributes differs. When these platform categories are mapped to the amount of support on these quality attributes, an overview can be made on how much effort it will take to realize a certain level for each quality attribute.
With an overview of the effort it will take to realize a certain quality attribute for the different cloud platform categories, a trade-off can be made in what to select for a cloud platform. And, while many cloud systems are a blend of categories, the overview should describe which parts of the system require more effort to realize the same quality level.
This is all about logical architecture, a task of assembling cloud components to reach the service level expected in each of the attributes.
People and Processes
Maximizing benefits from Cloud adoption also requires a new way of working and operational model. Business teams will become responsible for the build and run of their own Cloud Infrastructure (which lands on the platform). This new responsibility makes business teams more flexible, following an Agile and DevOps approach in their work. Business teams will have to align with each other on ways of working and coordinate for the ownership of the complete production landscape (including traditional operational IT managing legacy systems).
The focus of business teams should be on realizing and maintaining business functionality. Everything else is a distraction that should be done by others or executed in an automated way. To keep this focus, it is a good practice to follow a set of principles for the way of working. For example, general automation and work principles, practices, guidelines, and opinions for the way of working are in place to make sure that benefits and goals will be met.
Goals like:
- reduced cycle time.
- early feedback.
- increased predictability.
- lower software delivery risks.
These goals on the way of working can differ per system. For highly volatile systems on the cutting edge of innovation, the goals will be the ones mentioned above. For more stable functionality in the core of the company that doesn’t change at all, the goals will be different, which will also change the benefits of adopting the Cloud. These goals will be more like:
- low maintenance.
- self-healing.
- operational excellence.
- lower costs.
The first set of goals will be followed by systems which will adopt the cloud in Revise, Rebuild and Refactor ways while Lift Shift is more (cost) efficient for the last category.
System Architecture
A system with no external dependencies can evolve fast. A system which consists of many independent services can run these services in a flexible and efficient manner. These are two system architecture practices that have an impact on the benefits of adopting Cloud.
A key focus point with cloud adoption is the system architecture. Breaking a system up into small, independent services will bring more cloud benefits, but as mentioned above, in some cases, changing the system architecture and/or changing code isn’t the correct decision for getting the benefits out of Cloud adoption.
For example, when you split up a legacy system which doesn’t change anymore in to services, the trade-off between effort and Cloud adoption benefits won’t be good. For fast evolving systems and/or markets, this trade-off will be different.
For good services practices, read Martin Fowler’s Microservices Guide
Sogeti CloudBoost
A flexible, economic, and innovative business is one of the main goals companies have when adopting Cloud technologies.
The business wants to be at the innovation speed of the market!
Just opting-in for a Cloud subscription isn’t the silver bullet, nor is simply adopting a faster release cadence. A trade-off needs to be made between effort (time and money) and Cloud benefits: the more Cloud benefits, the more effort it requires when moving workloads to the Cloud.
A good trigger for this trade-off is when:
The business wants to get Legacy at the speed of Cloud from the transformation journey.
When creating new or rebuild workloads on the Cloud in a services architecture, a challenge will be that the business requires many more services which should be built in a consistent and maintainable way. After the experiment phase, the maturity and speed of realization should increase.
A trigger will be:
Large volume of Cloud Native systems.
Sogeti CloudBoost increases the Cloud adoption capabilities of the business by decreasing the effort it takes to gain Cloud benefits and by increasing the maturity (enterprise readiness) of the Cloud adoption.
Sogeti CloudBoost includes our industry best practices based on deep and wide knowledge of Cloud platforms gained from our current and past design, delivery, and run of cloud systems. The breadth and combination of development and operational knowledge make Sogeti CloudBoost an accelerator for businesses innovation via Cloud adoption.
Sogeti CloudBoost Library
The CloudBoost Library holds a Git repository with:
- Cloud resource templates in different formats (Infrastructure as Code),
- CI/CD Pipeline definitions from different DevOps tools (Pipelines as Code),
- Binaries (installer packages),
- Environment scripts in specific languages (Configuration as Code),
- Principles, guidelines, practices, and opinions on way of working, roles, and responsibilities.
The resources are organized as independent deployable components such that every component in the library can evolve independently. Artifacts in the Library will not contain logic specific to any business or project, and they are configured in a generic way to conform with industry and Sogeti standard practices. Every business project (and Landing zone deployment) can use them.
A build and release mechanism validates versions and drops the approved artifacts in a default location ready to be used by Business and Landing zone teams.
The Sogeti CloudBoost Library documentation holds the overview of available services and corresponding principles, guidelines, practices, and opinions for Cloud teams.
The knowledge and practices in the Sogeti CloudBoost Library artifacts evolve, the same as the capabilities of the underlying Cloud providers. To make sure the templates are always up to date and executable, the Sogeti Library team (and its global community of Sogeti Cloud brains) are continuously validating and updating not only the Cloud templates but also the scripts, pipelines, and guidance.
The Sogeti CloudBoost Library supports two different flavours to provide these updates to teams who are using the Library. The first flavour adopts the Sogeti CloudBoost library as-is. The Library is used as a Git submodule and updates are provided via Git pull commands. The second flavour gives more freedom to teams to change and adjust the templates for their own needs. Using a specific build, a version of Library artifacts is generated for the team with the trade-off that the adjustment comes with some additional activities and technologies.
CloudBoost Landing zones
Every adoption of a (single, multi and/ or hybrid) Cloud platform comes with a landing zone for business systems. A Cloud Landing Zone within a company provides a specific set of capabilities to business systems. This basic set of company Platform capabilities can be as simple as the identity directory (like Azure Active Directory), which every business system can use to provide login capabilities, to a complete set of specifically built and configured capabilities for the business or industry. These capabilities are almost always provided to the consumers as API’s.
The relationship between the landing zone and the business systems should be the same as the relationship between the Cloud provider and the company, a service provider <-> service consumer model. See image above.
IT shops are becoming service providers, providing the agility that the business teams require, while taking care that company security and governance regulations are being met.
Industry Landing Zone Examples
- Azure Security and Compliance Blueprint for PCI DSS-compliant Payment Processing environments
- AWS Landing Zone, a landing zone to provision AWS accounts. AWS Landing Zone deploys an AWS Account Vending Machine (AVM) product for provisioning and automatically configuring new accounts.
Sogeti CloudBoost Landing Zones
Sogeti CloudBoost Landing Zones are available in different flavors.
IaaS on Azure or AWS with industry best practice, like a spoke hub network setup and necessary servers for IaaS systems like, remote desktop, domain name and step stone services.
For container based micro-services systems, the Sogeti CloudBoost Landing Zones target multiple hybrid cloud platforms. Docker EE, OpenShift, and Azure Service Fabric are the preferred Container as a Platform services.
All Sogeti CloudBoost Landing Zones are built and available from the Sogeti CloudBoost Library and automatically released.
Cloud Business Projects
The overarching goal of the Sogeti CloudBoost Library is to support business projects in speeding up and increasing the maturity of Cloud adoption.
Let Business Teams focus on Business Functionality.
The setup and usage of the CloudBoost Library and Landing Zones aims to support and push business teams to work in a fast, flexible, and mature way. Having Infrastructure, Pipelines, and Configuration as Code available that conform to reference architectures and industry best practices will enable business teams to accomplish this goal.
Overview
Sogeti CloudBoost contains multiple offerings to maximize the efficiency of Cloud adoption. The Sogeti CloudBoost Library contains (see image below):
- Library with template
- Landing Zones for security and compliance
- Business project DevOps support
