Determine the individual path to the cloud in a structured way
The path to the cloud is different for each organization and it is important that it is structured and comprehensively planned to allow the smoothest possible transition. Set goals and develop processes for your individual path into the cloud. In addition to the often technical challenges to be solved in the actual migration, other aspects play a crucial role. In a holistic approach the planning of the specific cloud journey is most importend in order to make a successful transformation into a “cloudified” enterprise. Based on the AWS Cloud Adoption Framework, the individual roadmap can be planned here. In doing so, the CAF is based on generally accepted best practices and can therefore be used (largely) detached from the targeted cloud platform.
Perspectives and priorities in the Cloud Adoption Framework
The CAF consists of six perspectives that divide the extensive planning process into manageable focus areas, each with different target groups and responsibilities.
Three of the perspectives are aimed at those involved in IT and thus shed light on the technical basis: platform, security and operation. The three other perspectives (business, people and governance) cover the entrepreneurial aspects. Then there is the consideration of the degree of maturity, which was integrated in February 2017 into the other six perspectives.
The focus in this perspective is on the people or employees. This perspective deals with personnel development and training in the cloud sector. In this area to be clarified questions are e.g. “How can suitable teams be put together”, “How can know-how be built up quickly?” and “Which skills or training courses make sense for which employees / groups?”.
The People Perspective shows a pathway to an agile organization that is well-positioned for effective cloud transformation and often requires major organizational changes. In this context, it is important to examine the existing organizational structures, to evaluate existing skills and processes, to uncover gaps and systematically address them. Start training your employees’ skills early, give free space for cloud education (e.g. attending summits, fairs and developer days), let your employees be builders. A possible approach to a quick skill set-up is the consistent and regular implementation of hackathons on cloud issues.
The focal points of this focus are Human Resources, Resource Managers and Personnel Training.
The business perspective focuses on ensuring that IT development is aligned with business needs, and that IT investment and the resulting business results are measurable and traceable. It is important to involve relevant stakeholders from the beginning in cloud adoption and work together to develop a viable business case. Here, IT and management must develop a common strategy and prioritize cloud initiatives. It is important to record quick successes (“quick wins”) by identifying so-called “low hanging fruits”. In other words, which aspect or application can be brought to the cloud with relatively little effort (keyword: “Lift & Shift”), but has a great value for the company?
The main focus of this perspective is on management, strategy developers and budget administrators.
The Governance perspective addresses portfolio management, program and project management as well as license management and business performance.
Portfolio management needs to identify the mechanisms that drive the cloud and prioritize the use of cloud services in day-to-day business. Furthermore, it has to be answered how strategic portfolio elements can be developed that can support and promote the newly established cloud strategy in the company.
From the point of view of program and project management, a rethinking of the traditional waterfall model towards agile methods is necessary to keep pace with the rapid development of cloud service providers. It is important not only to further develop the team, but also to establish a new mindset in the management levels.
The main focus is on project managers, portfolio managers and program managers.
The platform view includes the structuring of the available cloud architectures in order to describe in detail possible target architectures for the respective applications. It would be desirable if the same procedures for different applications can be used again (“templating”). Both possible migration paths and the development of new applications are covered from this perspective.
The focus is on the resources:
- Compute: Modeling and provisioning required resources such as memory or CPUs for enterprise applications. The key points here are that other skills are needed here than computing and managing a data center. The known processes are shifting from a “real world logistic” more and more to virtual and above all completely automated processes.
- Network: Again, a transition of thought and procedure in the field of virtual provisioning is necessary. Of course, firewall appliances can still be deployed in virtual machines in the cloud, but much of the configuration will be done through security groups. Important when setting up the networks: Align the AWS address ranges with your corporate network at an early stage to avoid unpleasant surprises when establishing a Direct Connect connection between AWS and your on premise data center. Avoid using the “default” networks.
- Storage: The handling and provisioning of storage also needs to be rethought in the cloud. Here again the procurement channels (real vs. virtual logistics) but also the technical handling play a role. The AWS cloud storage types cover a wide range of applications, from scalable storage in multiple grades (S3) to block storage for EC2 instances (EBS) to archival storage (Glacier), which is very cost effective but typically offers slow accessibility. Take a comprehensive look at what your storage strategy should look like in the future. You might consider the use of a storage gateway to combine the advantages of an on premise solution with those of the cloud.
- Database: Available databases range from classic RDMS to cloud-native databases. From Oracle, MS SQLServer to PostgreSQL and MariaDB to fully managed databases such as Aurora, Amazon DynamoDB or Neptune as a graph database service, the right choice is here. To help with minimal downtime migration, the AWS Database Migration Service is there in place to assist. For example, even Oracle databases can migrate to PostgreSQL.
There are also the overarching areas of system and solution architecture and application development. Strategic cloud targeting is also changing the demands on system and solution architects. With cloud-native services and using virtual components (networks, gateways, storage, etc.), complete architectures (traceable and repeatable) can be described in structured text files (JSON, YAML) (see AWS Cloud Formation or Terraform). This approach, referred to as Infrastructure as Code (IaC), provides a foundation for introducing DevOps in your organization. From a developer’s point of view, this includes Continuous Integration and Continuous Deployment (CI / CD) to enable agile development and deployment of applications in the cloud. In addition to the above-mentioned aspects, in the future it will increasingly be necessary to weight up the extent to which basic cloud components such as storage and compute include cloud-native services in development. Ultimately, this is always a cost / benefit calculation.
The main focus is on system architects, solution architects, software architects and developers.
“Security at AWS is job zero”
That’s what the CAF white paper describes. At AWS, the Shared Responsibility Model applies – AWS ensures security of the Cloud and the customer is responsible for security in the Cloud. The general model and associated responsibilities are shown in Figure 2.
Depending on the type of service (PaaS or IaaS), the respective area of responsibility may shift further. For relevant aspects, the following characteristics should be considered in this perspective:
- Identity and Access Management: AWS provides the ability to: For example, to set fine-grained access to resources and data based on users, groups, roles, and policies. It would be best if you put the credentials for your root account into a vault right after creation and work exclusively with dedicated accounts with limited rights. Someone with access to your root account can manipulate or shut down your entire infrastructure.
- Detective Control: In general, AWS has sophisticated logging capabilities (Cloudwatch) and traceable provisioning of resources (CloudTrail) that are close to real-time needs. But ultimately it’s mostly about the correlation of different events. AWS recommends bringing your own logging services with those from the application and the operating system. Here also often external solutions, such as Splunk (which can also operate in the cloud) are used to provide insightful information in case of error. It is important that this is about the security “in the cloud”, so in responsibility of the customer.
- Infrastructure Security: Because the cloud can “breathe” the infrastructure in the cloud-adapting to workloads and business needs-at any given time, establishing infrastructure security must also be manageable in an agile manner. It is important to automate the entire process (build – deploy – operate) in the area of security.
- Data Protection: deals with the configuration of visibility and control over data. Who has access to which data? Which policies or rights apply? Have these rights been set as minimal as necessary?
- Incident Response: Here, it is important to establish appropriate strategies for dealing with incidents in your company in order to reduce their impact, communicate in an appropriate manner and restore operation as quickly as possible. In the case of cloud adoption, it should be considered whether the focus of security experts should be on the direct response to security incidents rather than on forensics and root cause analysis. The reconstruction of the environment will be script-controlled even without them.
The main focus is on: security experts, but also (system / solution and software) architects and operations.
This focus evaluates the current status of the company’s operations and defines the steps needed to develop it “cloud-ready”. The goal is to enable Operations to plan, deploy, deploy and operate IT workloads in the cloud, and restore them when needed.
The following points are considered:
- Service monitoring: With the use of cloud technologies, the handling of service outages can be automated to a large extent, resulting in significantly better availability. Again, it is again true that for the cloud adoption intensive knowledge building must carried out to make use of the new opportunities that comes with the cloud (e.g. automatic re-deployment of an application on another EC2 instance in case of failure based on IaaS).
- Application Performance Monitoring: Gone are the days when, at the beginning of the project, the infrastructure was set up in the form of servers (or VMs) and never changed again afterwards. It is about the permanent monitoring of the utilization of systems to bring a continuous optimization from both cost and performance. At Storm Reply we can help you on continuesly saving money while operating new workloads in the cloud.
- Resource Inventory Management: In the area of the cloud, hardware asset management reduces hardware lifecycle management and license management to a minimum. Databases can be e.g. including matching licenses and will be charged “on demand”.
- Release Management / Change Management: This point is about establishing a new path – away from classic Release Management to an agile process based on CI / CD that can quickly and safely roll out new releases but also roll back them again. For example, with a micro-service-oriented architecture, each development team can build, deploy, and most likely run their part of the application independently of the other teams. There’s a nice saying here in the DevOps section: “You built it, you run it,” which also applies to all AWS services.
- Reporting and Analytics: Involves in the definition of service-level agreements (SLAs) and operational-level agreements (OLAs) as well as the continuous analysis of these and the associated reporting. Operations should look into the benefits and new opportunities that come with deploying the cloud in this area.
- Business Continuity / Disaster Recovery (BCDR): Many of the existing (“classic”) processes around BCDR are changing in the cloud. This is about the continual build up of knowledge and the development of new strategies resulting from the extended functions (e.g. Multi AZ Deployments for databases, different redundancies at S3, automated instance backups, failover and automatic redeployment for unavailable EC2 instances). If, in fact, a full availability zone should fail, there are more data centers in the region, or operations can be resumed in some other region (partially automated). It is important to take advantage of the benefits of the cloud and plan strategically with it.
- IT Service Catalog: What services should your company provide? Which SLAs are behind it? Here, it is important to establish a loose connection between desired and future services from the point of view of IT, but also with the perspective of portfolio management.
The main topics addressed are: operations.
The Cloud Adoption Framework, or its rough outline in this article, uses a variety of topics to show how to transform to a cloud-enabled enterprise. The next step is to shed light on the six perspectives outlined in detail and to work out an action plan. In the document “Creating an Action Plan” you will find further concrete steps with which you can start with the CAF directly. We at Storm Reply will gladly help you further and accompany you on your journey to the cloud.