In those two years, we learned and practised. With our history from mainframes, Unix and telco world our cloud journey just got started.
Not a long time ago we asked our customers about how many CPUs & how much memory they will need. Alternatively, we recommended virtual machines as a solution.
Since then, we have figured out that “serverless” doesn’t only refer to using AWS Lambda (Function as a service) for your compute needs. In reality, serverless encompasses as much as seven different layers, each with different concepts. The realization forced us to pause and carefully consider which path we take. After a lengthy debate, the AWS Tiger Team decided to embrace the paradigm shift and step into the unknown. We had to abandon the Old World and the tried and tested technologies we had become so familiar with. Going forward, we would always challenge ourselves to a “cloud-native, serverless first” approach.
The first problem we decided to tackle with that approach was the remove all manual steps in the synchronization of AWS accounts into Confluence. As the number of AWS accounts kept growing, it was becoming increasing tedious to maintain accurate and up-to-date documentation on those accounts. We used API Gateway with Basic Auth for Confluence to make the call to Lambda. We handle the sensitive data by using AWS Systems Managers Parameters Store and AWS Key Management Service. Lambda itself will AssumeRole (instead of managing access key and secret keys) to list accounts details in AWS Organization. Using what we learnt, we were able to extend those principles to using AWS Steps Functions to model the complex workflows involved with account onboarding and offboarding. We also used Code Pipeline to build, test and deploy changes into production. We are continually improving it.
Every journey starts with the first step, and we had quite a few bumps and trial and errors. Not only emotional, but the adjustment of making loosely coupled components to work together was also mind-boggling. We begin to realize the potential and benefits of serverless — no more infrastructure to manage; endless scaling; built-in fault tolerance and lower cost.
We take security very seriously, so we were keen on including security in all of our solutions. We have been able to rely on Cloudwatch Events and GuardDuty. CloudTrail is enabled on all accounts, with all API calls logged, archived and analyzed in a fully serverless fashion. This means that for critical events, the Tiger Team gets notified within just a few seconds. Getting there generated a lot of learnings, which we shared through our Cloud Security Whitepaper and a presentation “Security – Don’t leave it for later” we delivered at AWS Summit Switzerland. Check out those if you are interested in the Cloud Security.
With our practices and discovery of the serverless, we started to build our first internal customer-facing application. A service that helps allow the user to control their EC2, RDS and Sagemaker Endpoint. The solution is to reduce the cost for none 24×7 workloads by sending a message in Slack. To start or stop the Sagemaker endpoint or scheduled tasks. For example, having a demo with Sagemaker Endpoint for the machine learning inference. It should be stopped when no ongoing demo.
Two years on the serverless journey, we travelled like a child found a new world of opportunities. We built a solid Cloud Foundation on AWS with Billing, IAM, Security & Compliance, Account & Organisation and took a significant path on the journey to master the serverless technology. Discovering the cloud and beyond!
Do you deal with Amazon Web Services in your company and would you like a personal exchange? Our cloud experts will be happy to answer your questions: Contact
Further information on Swisscom’s service portfolio for Amazon Web Services can be found at www.swisscom.ch/aws.