This is our new cloud infrastructure
After many years of using cloud services from various providers such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud and IBM Cloud, we are now back to where we started and are mainly using AWS. Over the past year, we have worked hard with our partner Webstep to professionalize the use of AWS in several of our business areas.
Amazon Web Services (AWS)
Datek has been using the world’s largest cloud service, Amazon Web Services (AWS) since 2007. During that time, AWS has been constantly expanding its service offering and Datek has been using ever more services. Over time, we have seen the need for a cleanup and a new way to set this up, which we engaged AWS partner Webstep to help us with. This article explains what our new cloud setup looks like and the motivation behind the choices we’ve made.
The journey towards our new cloud infrastructure
Over time we have experienced that resources and settings in the cloud quickly become hard to manage effectively. It is not trivial to keep track of all the setup in the cloud that are relevant to a given service. Similarly, given a resource or setting in AWS, it is not always easy to see who is using it or whether it can be safely removed. Amazon Web Services makes it easy to make changes right in a web management interface and there are quickly many settings that you do not have a complete overview of.
This has implications for:
Cost savings (not trivial to clean up/remove services)
Security
Cost allocation
Traceability
Operating stability
Recovery
Setup for new customers
A cloud service is often divided into who will pay for it (system/customer) and environment (whether it is for test, QA or production). Hard separation of these axes is a trade-off against reuse of services and economies of scale. Fortunately, good tools have emerged in recent years that can help us with these problems.
Infrastructure as code
Instead of clicking in a web management interface, all the cloud setup is now created in source code which is then uploaded to the cloud and automatically sets up all services.
Infrastructure as code makes it easier to:
Have version control (full history, ability to review changes with a colleague, controlled rollout of changes)
Make multiple copies of a system quickly
Have a complete overview of all resources and settings for a system, e.g. for security review and cost control.
As a tool for infrastructure as code, we have chosen AWS CloudFormation which is well integrated with AWS. The tool makes it easy to create reusable templates for services and provides us a very good overview of resources for a service.
Beyond CloudFormation, we automate everything that can be automated with various tools using version-controlled files. No changes should be made directly in a web interface, if this is possible to avoid.
One AWS account per customer/environment
In the new setup, we have chosen to have a hard separation of different projects/customers and environments (test/qa/production) by creating own AWS accounts for all verticals (i.e. combinations of project/customer and environment). This simplifies access control (role-based access), cost distribution and minimizes risk when making changes.
“Serverless” services
We use as many serverless services as possible, i.e. services where you do not need to operate a virtual machine operating system in the cloud. This removes the need to run security upgrades on the operating system level and there are generally more readily usable services available.
Serverless services we use in AWS include ECS with Fargate and Lambda.
Continuous integration
Building source code is best done in a controlled environment so you don’t get a developer machine specific build that can’t be recreated later, so we build all code in the cloud with AWS CodeBuild and CodePipeline. Libraries are built at GitHub with GitHub Actions and Package Repository.
Security in depth
All services should have multiple layers of security, for example encrypted connections (also for internal services in a vertical), access control (tokens or username / password – also for internal services), closed networks (VPC, VPC peering or IP address control ) and two-factor authentication for all management interfaces, to name a few.
Infrastructure as code makes it easier to ensure good security in the services, since you can reuse templates of setup from other services with good security and do code review with a colleague before setting it up in the cloud.
Satisfied with the project
«Webstep has been a very competent partner in this process and there has been a good collaboration between Webstep and our DevOps engineers. Arne Solheim is a skilled advisor and made sure we got a lot out of this process», says Christian Schwarz, who was the technical lead for the project.
Datek has also migrated to a resell model where Webstep is an intermediary between Amazon Web Services and Datek, so that all AWS cloud costs come on a traditional invoice to Datek. This means that we avoid using credit cards as a payment method to AWS.