ISSUE 188: Microservices the World Over

“Kubernetes ‘done right’ can eliminate a big part of developer grievances, but on the flipside, ‘Kubernetes done wrong’ will come back to haunt you with a vengeance.”

In order to achieve its goals as both Switzerland’s largest telecom and as an IT provider, it became apparent to Swisscom three years ago that it had to find ways to scale across its entire operations in a way that remained consistent and robust. It would be a challenging task, given that it had a client-server dependency.

In this The New Stack Makers podcast recorded at Cloud Foundry Summit EU, Lukas Lehmann, head of cloud services for Swisscom, discussed how his organization was able to achieve its shift to at-scale application development goals across cloud environments thanks largely to a partnership with Cloud Foundry. Stefan Voegele, expert middleware engineer for insurance provider Swiss Re, was also on hand to discuss how his firm uses Swisscom’s Platform as a Service (PaaS) in its shift to a cloud environment.

Microservices the World Over

It seems like only a few years ago when The New Stack was driven simply by founder Alex Williams traveling the world with his trusty recorder. These days, however, TNS is expanding its tentacles across the globe! This week we were covering the news at events across two continents and three different time zones.

In Austin, Williams and news reporter Mike Melanson were on the ground covering the SpringOne Platform conference. There, Pivotal and Microsoft unveiled the private preview of Azure Spring Cloud, a fully managed service for deploying Spring Boot applications on Microsoft Azure. Spring Boot offers the basis for creating modern microservice applications without developers having to worry about infrastructure.

In Barcelona, our European correspondent B. Cameron Gain learned, at SAP TechEd 2019 conference, how SAP is using Kubernetes and Cloud Foundry to power its enterprise cloud services. The new cloud offerings will run on Cloud Foundry services and microservices as well as Kubernetes clusters, SAP executives said during the conference. Ultimately, the new cloud offerings are largely intended to boost DevOps’ access times to data.

Back in Portland, at the Puppetize PDX event, TNS Editorial and Marketing Director Libby Clark brought us news of Puppet’s new Project Nebula, a cloud native tool that connects a DevOps team’s existing toolset into an end-to-end continuous delivery platform. The company aims to simplify deployment of microservices and serverless-based applications by connecting popular tools for infrastructure provisioning, application deployment, and notifications into a single, automated workflow. Project Nebula is built on top of Tekton, the open source project started at Google and donated to the Continuous Delivery Foundation (CDF) last March.

Stayed tuned to The New Stack for the news of microservices, DevOps, and cloud native computing — from the world over.

Amidst Controversy, the Knative Serverless Software Keeps Growing

The announcement last week that Knative would not be donated to a foundation anytime soon was met with disappointment from many. Nonetheless, the software is being increasingly adopted by major players in the cloud native space, including IBM, Red Hat and SAP.

Kubernetes ‘Billion Laughs’ Vulnerability Is No Laughing Matter

A new vulnerability has been discovered within the Kubernetes API. This flaw is centered around the parsing of YAML manifests by the Kubernetes API server. During this process, the API server is open to potential Denial of Service (DoS) attacks. The issue (CVE-2019-11253 — which has yet to have any details fleshed out on the page) has been labeled a “Billion Laughs” attack because it targets the parsers to carry out the attack.

Flockport: Time to Start All Over Again and Return to LXC Containers

Flockport started out in 2013 as an app store for server-side applications before shifting its focus to become an alternative for more complicated solutions like Kubernetes, which Flockport founder Indrajit Banerjee says introduces far more complexity and requires far more expertise than most companies can handle. The problem, Banerjee says, came with the move away from LXC and three specific design decisions made by Docker.