Learning—and teaching—the art of service-level objectives — CRE Life Lessons

Avid readers of CRE Life Lessons blog posts (there are dozens of us!) will appreciate the value of well-tuned service-level indicators (SLIs) and service-level objectives (SLOs). These concepts are fundamental building blocks of a site reliability engineering (SRE) practice. After all, how can you have a meaningful discussion about the reliability you want your services to achieve without properly measuring that reliability?The Customer Reliability Engineering (CRE) team has helped many of Google Cloud’s customers create their first SLOs and better understand the reliability of their services. We want to make sure that teams everywhere can implement these principles. We’re pleased to announce that we’re making all the materials for our Art of SLOs workshop freely available under the Creative Commons CC-BY 4.0 license for anyone to use and re-use—as long as Google is credited as the original author. We’ve been inviting customers from around the world to this workshop for the past year. From now on, anyone can run their own version of this workshop, to teach their coworkers, their customers, or conference attendees why all services need SLOs.What’s covered in the Art of SLOsThe Art of SLOs teaches the essential elements of developing SLOs to an audience from across the realms of development, operations, product, and business. The workshop slides are accompanied by a 28-page supporting handbook for participants, which is part reference and part background material for the practical problems that workshop participants engage with.In the workshop, we start by making a business case for the value of SLOs based on two fundamental assertions. First, that reliability is the most important feature of any service, and second, that 100% is the wrong reliability target for basically everything. These assertions underlie the concept of an error budget, a non-zero quantity of allowable errors in a given time window that arises from an SLO target set somewhere just short of 100%. The tension between a fast pace of innovation and service reliability can be resolved by aiming to roll out new features as fast as possible without exhausting this error budget.Once everyone is (hopefully) convinced that SLOs are a Good Thing, we explain how to choose good SLIs from the wealth of telemetry generated by a service running in production, and introduce the SLI equation, our recommended way of expressing any SLI. We cover two alternate ways of setting your first SLO targets, which arise from making different tradeoffs, and offer advice on how to converge these targets over time. We introduce a hands-on example—the server-side infrastructure supporting a fictional mobile game called Fang Faction—and use it to demonstrate the process of refining an SLI from a simple, generic specification to a concrete implementation that could be measured by a monitoring system.Art (noun): A skill at doing a specified thing, typically one acquired through practice.Critically, participants put this newly acquired knowledge to practical use straight away, as they develop more SLIs and SLOs for Fang Faction. Typically, when we run this workshop with customers, we break them up into groups of eight or so and unleash them on the workshop problems for 90 minutes. Each group is paired with an experienced SRE volunteer, who facilitates the discussion, encourages participation, and keeps the group on track.Run your own SLO workshop!If this sounds interesting, you’ll want to check out the Facilitators Handbook, which has a lot more information on how to organize an Art of SLOs workshop. If you don’t have a whole team to educate, you might be interested in our Measuring and Managing Reliability course on Coursera, which is a more thorough, self-paced dive into the world of SLIs, SLOs and error budgets.
Quelle: Google Cloud Platform

Modernize your apps with Migrate for Anthos

In a perfect cloud world, you would host all your applications in containers running on Kubernetes and Istio, benefitting from the portability and improved resource utilization of containers, plus a robust orchestration platform with advanced application management, networking, and security functionality. This is easy to do if you’re developing a new application, but it can be hard for existing applications to take advantage of those capabilities.Many of the applications that you may want to move to the cloud have been around a long time, and you may not have the application-specific knowledge that would be required to rewrite them to be more cloud-native—or it would be incredibly time-consuming to do so. Another option is to lift-and-shift to a virtual machine (VM) hosting platform like Compute Engine, but that means you still need to maintain the VMs. Even if you’re not able to fully modernize an existing app, it would still be great to get some of the benefits of containers and Kubernetes.What is Migrate for Anthos?Enter Migrate for Anthos, a fast and easy way to modernize your existing applications with a service that encapsulates them in a container. Moving your physical servers or existing VMs into Kubernetes containers gives you crucial portability and resource utilization benefits without having to rewrite the underlying application. Since Migrate for Anthos is built for Google Kubernetes Engine (GKE), you also automatically capture the scaling and flexibility benefits of a managed Kubernetes environment in the cloud. Migrate for Anthos recently became generally available.Converting an application with Migrate for Anthos happens in two phases. First, it creates a generic container wrapper around your application that makes it seem like it is still running in a full VM environment. Then, you launch Migrate for Anthos software on your Kubernetes cluster that runs the containerized application. You can find more details about this in the documentation and in our blog post: Migrating from Compute Engine to Kubernetes Engine with Migrate for Anthos.As the name suggests, Migrate for Anthos works with Anthos GKE. However, you can also use Migrate for Anthos with only GKE—all it  requires is your application and a GKE cluster running the Migrate for Anthos software. Getting started with Migrate for AnthosMigrate for Anthos works with a variety of workloads, but not all. It’s particularly adept at migrating legacy applications, stand-alone applications, and monolithic applications. As you start start the modernization process, here are some questions to ask to determine whether to use Migrate for Anthos with your applications:1. Should this app be in the cloud?By its nature, the cloud may not be able to support some characteristics of your on-prem environment, such as geography and legal compliance. The best way to find out whether the cloud will work for each of your applications is to plan out a full migration. That will allow you to identify groups of applications that can benefit from cloud offerings such as a global network and ease of resizing resources. After that, try out a proof of concept by testing the apps in the cloud to see if it fits your business needs.2. Should this app be in Kubernetes?Containerizing an application simplifies workload administration, improves scalability (both up and down), and increases host utilization. Kubernetes orchestrates the containers and GKE handles node upgrades, while add-ons like Istio let you manage network and security policies independently of your application.With those advantages it’s easy to think that containers are always the right way to go, but there are some cases where it may make sense to stick with VMs. Strict hardware requirements, specialized kernel modules, and license constraints may be harder to run with containers, negating their advantages.3. Should this app migration use Migrate for Anthos?Migrating your apps or workloads to the cloud isn’t just about shifting where the compute resources run; it’s also an opportunity to modernize them with containers. Using Migrate for Anthos (or Migrate for Compute Engine) gives you the ability to get your workloads in the cloud quickly, with minimal upfront downtime that’s easy to plan for. However, even if you use the Migrate for Anthos wrapper, your application is still the same application. The benefits of the modern platform may not outweigh a legacy application and a rewrite may be the only way to meet your business needs. There are also some specific services from your VM that may not work with Migrate for Anthos, for example licensing requirements.Migrate for Anthos can also be the first step on a larger migration effort. Once you’ve migrated the application to GKE, you can gradually break up a monolithic app into microservices by manually rewriting parts. Spreading out the migration effort gets you in the cloud sooner, giving you more time to modernize.Next stepsA successful modernization starts with creating a full migration plan, testing the workloads, and monitoring them. You can experience the benefits of modernization with Migrate for Anthos by picking a small workload and trying it out for yourself!As you test different workloads for your migration, be sure to reference the documentation. And keep an eye out for an upcoming blog series on the migration process. Our first blog steps through how to modernize a Compute Engine instance and host it on GKE.
Quelle: Google Cloud Platform

SteelHouse cuts application deployment time in half with IBM Cloud Kubernetes Service

People who are shopping, researching, or doing anything at all online don’t want to be held up by a website that takes a long time to load. And, ads are one of the most common reasons for poor website performance.
SteelHouse uses the IBM Cloud to ensure a good user experience, which for the advertising software company translates to an ad being served in approximately 100 milliseconds or less.
With the cloud, we’re able to deploy all over the world and we don’t have to worry about the orchestration or the time that it takes to serve an ad.
A fully managed Kubernetes service
We run a lean organization. For us to continue to compete and deliver great products, which in our case are optimized ad campaigns based on users’ browsing histories, we needed to offload as much as we could to other providers.
We had worked with bare metal machines and VSIs (virtualized server instances), and we were very interested in moving into an ecosystem where we didn’t have to do a lot of managing.
When we found out about the IBM Cloud Kubernetes Service, we chose it as our compute engine because we could standardize how we deployed and how we scaled. By running everything inside Kubernetes, it allows us to have a simple, streamlined environment with a fully managed container service for Docker (OCI) containers. This allows us to be able to deploy containerized apps onto a pool of compute hosts.
We didn’t have to do a Kubernetes installation; we just had to learn how to use and operate Kubernetes. This was simple, in part because the Kubernetes service team at IBM provided great support in getting us up to speed and helping us feel confident that we could move forward in a cloud environment running Kubernetes.
Complementary cloud technologies
Moving to a microservices architecture without Kubernetes would’ve been a nightmare. We have almost 40 microservices under our belt and Kubernetes helps us orchestrate and manage those services. Without that, the amount of manpower required to maintain and service that infrastructure would be magnitudes higher than we can currently accommodate with our staff.
We use IBM Event Streams for IBM Cloud to decouple the back-end services that do the heavy lifting from the front-end services that provide customer interaction. That way, the customer interaction isn’t degraded when we’re doing heavy processing in the back end. IBM Event Streams allows for playback of data that teams may not have been able to process or may need to be reprocessed. If needed, reloading data into the database is just a click of the button.
Additionally, because SteelHouse is part of the Cloud Native Computing Foundation user community, we like to ensure that we use as many products that are part of the foundation as possible, including Istio.
Istio is a service mesh that runs inside Kubernetes routing traffic in between services and blocking unwanted traffic from coming into the network. We chose Istio as our service mesh for the security that it provides and the ability to do retry logic on HTTP requests. Many of our services make HTTP requests to other downstream systems, but those HTTP requests can sometimes fail. Istio provides retry logic without us having to modify our code, which means we don’t have to test and configure applications – it’s just configurable at the service level.
Synergy among the team
By working with IBM Cloud Kubernetes Service, we can offload all the operational work and support and stay focused on the actual products that we’re building.
With the Kubernetes service we can spin up a new data center in 24 hours. It used to take us a month. The service is also helping us reduce ramp-up time for new hires, because it doesn’t take them two months, or six months, or a year to get up to speed and actually deploy something. It now takes them literally a week.
One of the big things that happened when we switched to Kubernetes was that developers began to take control of how applications were configured and how pipelines were built out. This took workloads off of the operations team’s plate and created a new team synergy. Now instead of having to rely on a separate team to do configuration management, our developers can build their own Docker files and deploy content to the cloud instead of running it locally on their machines. Generally, running on Kubernetes has made it possible to deploy things in half the time it used to take.
Overall, we have the ability to move faster, develop and deploy quicker, and have better insight into our applications. We can do all of this with a better service-level agreement (SLA), because we are able to use cloud-managed services that make our team seem bigger than it is.
Watch the video and read the case study to learn more about the SteelHouse journey.
The post SteelHouse cuts application deployment time in half with IBM Cloud Kubernetes Service appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

Community Blog Round Up 09 December 2019

As we sail down the Ussuri river, Ben and Colleen report on their experiences at Shanghai Open Infrastructure Summit while Adam dives into Buildah.
Let’s Buildah Keystoneconfig by Adam Young
Buildah is a valuable tool in the container ecosystem. As an effort to get more familiar with it, and to finally get my hand-rolled version of Keystone to deploy on Kubernetes, I decided to work through building a couple of Keystone based containers with Buildah.
Read more at https://adam.younglogic.com/2019/12/buildah-keystoneconfig/
Oslo in Shanghai by Ben Nemec
Despite my trepidation about the trip (some of it well-founded!), I made it to Shanghai and back for the Open Infrastructure Summit and Project Teams Gathering. I even managed to get some work done while I was there.
Read more at http://blog.nemebean.com/content/oslo-shanghai
Shanghai Open Infrastructure Forum and PTG by Colleen Murphy
The Open Infrastructure Summit, Forum, and Project Teams Gathering was held last week in the beautiful city of Shanghai. The event was held in the spirit of cross-cultural collaboration and attendees arrived with the intention of bridging the gap with a usually faraway but significant part of the OpenStack community.
Read more at http://www.gazlene.net/shanghai-forum-ptg.html
Quelle: RDO