“We like to tell the story of how we as a Swisscom DevOps team became Swisscom customers,” says Roman Bachmann, a DevOps engineer for the company.
“We are, in essence, eating our own chocolate.”
Step by Step, Bit by Bit
The Swisscom team has been working for the past few years moving to microservices from a monolithic architecture. It deploys the admittedly unappetizing phrase “strangling the monolith” to describe its strategy, which involves moving workloads piece by piece while maintaining uptime for its users.
Its approach is based on a strangling pattern developed by extreme programming guru Martin Fowler, in which a functionality is first deprecated on the monolith, its workload moved to a microservice, then the functionality removed from the monolith.
“There is no way to migrate everything at once,” Roman says, “so we follow these three steps, doing it over and over again (thus slowly ‘strangling the monolith’) until there is no workload left.”
The old system and its infrastructure is then phased out.
This is a valid and worthy process for Swisscom – as of September 2018, the internal Swisscom team manages more than 900 Cloud Foundry orgs running 6,000 apps, while allocating 7TB of memory to them. The usage of key database technologies Redis and MongoDB within this new infrastructure has approximately doubled over the past year.
Swisscom’s monolith was running along an enterprise service bus (ESB), with aggregation, orchestration, and composition of data and services done in the back end. Mobile apps and other “front-end stuff,” according to Roman, “were done in a classical way with waterfall tech requirements coming to us from places throughout the system.”
The Swisscom team is focused less on point solutions and more and more on digital products, for which they try to find a demand then create more generic solutions in the areas of VOIP and active messaging.
An Unstable Annoyance Emerges
The hunger to deploy on cloud originated in a particular case that had started with a small (albeit expensive) workload, which then grew to a very heavy workload that degraded the monolith’s performance and started to make it unstable.
The dilemma was to find an approach that maintained customer service but ridded the company of a system that “we were pretty annoyed with,” Roman says. Introducing a microservices architecture also meant following the 12-factor app process which, when completed, reduces tasks related to the infrastructure.
The question then became whether the Swisscom cloud was the right place to run these new services. The company’s IAPC (Internal Application Cloud) launched in January 2017, initially providing an identity service, a smart messaging suite, and “connectivity-as-a-service,” which managed connectivity requests originally made to the legacy system.
Along the way, the team completely rebuilt its CI/CD pipeline, which resulted in enormous success.
Code changes that would take a day or even weeks to get into production now take only five minutes from check in, testing, integration, test acceptance and deployment to production.
Nginx Buildpack To the Rescue
For those asking, yes, there is complexity in many forms on this menu. A reverse proxy and related features were required, so the Swisscom team found Cloud Foundry’s Nginx buildpack was ideal to address these issues. With it, they were able to define every migration step, do some canary releases (another Martin Fowler principle in which releases are slowly rolled out to a subset of users), and therefore move around 1% to 10% of specific workloads to the microservices platform.
The team was ultimately able to move the whole workload from the monolith to Cloud Foundry using the buildpack configuration out of the box, along with cloud native technology like the Spring Cloud gateway and service mesh, Roman says. “We were also able to put monitoring on top of traffic management and thus convert traffic data to metrics.” The team could monitor response times, for example, and see how the integration was actually working.
“We are cloud users, not a cloud development team, so we are consuming resources,” Roman reminds us. “We’ve learned a few lessons along the way.” The primary lesson?
“Don’t overwhelm your customers, but keep them in the loop.”
The Process Continues
The Swisscom internal tech stack includes Mulesoft, F5 app services, ActiveMQ, Apache servers, Oracle, and Splunk. But through the use of Cloud Foundry and the Spring Boot framework, the team’s responsibilities for troubleshooting, tweaking, and optimizing is simplified through the use of standard services “and community stuff,” Roman says. The team is able to scale out and in as it needs, and improve its overall code by removing code that was implemented six years ago that was rarely if ever used.
After all this, the ESB is still there, but it continues to phase out all the load balancing, certificates, VMs, and tools that were originally deployed on bare metal. The team is looking forward to embracing autoscaling as it becomes available, and is now working to integrate Cloud Foundry’s CredHub centralized credential management component as soon as possible.
Overall, the Swisscom team strongly encourages DevOps teams to migrate from bare metal to this platform.
“We found that the monolith can be split up into multiple microservices and you can go with a Platform-as-a-Service (PaaS) approach.”
You can thus not only eat and consume well, but sleep well, too.
For readers wishing more information, Swisscom’s Roman Bachmann and Fabian Hoffschröer discussed Swisscom’s use of its own cloud during a presentation at the 2018 Cloud Foundry Summit Europe:
