devopsy.kinsta.cloud

Tag: Google Cloud

  • How to Secure Your Kubernetes Cluster on GKE

    How to Secure Your Kubernetes Cluster on GKE

    Google Kubernetes Engine (GKE) is easy to get going with, but requires additional security controls. The documentation is hard to grasp as there are many features and changes that tie to specific Kubernetes versions that will require using beta feature enablement, as well as some out of date documentation that can catch people out.

    There is also an outstanding bug that we have raised on Kubernetes that is hit by GKE. This is an edge case situation if you end up running pods directly and not deployments, and only happens if you enable pod security policies (which we recommend doing for security reasons).

    If you are looking at production and have sensitive workloads, we advise that you implement everything inside of this article.

    Securing Your Kubernetes Infrastructure

    When you deploy a default GKE cluster with no additional options provided, you’ll get some sensible security defaults:

    1. Basic authentication is disabled.
    2. Encryption at rest for the Operating System (OS) image is enabled.
    3. Client certificate issuance is disabled.
    4. Secure Operating system (Using Container-Optimized Operating System; COS).
    5. VM Integrity monitoring to protect from malware/rootkits.
    6. Restricted Service Account.

    So, why did Google enable these things by default? Essentially it means:

    • You can only authenticate via Google Cloud Platform (GCP) Single Sign On (SSO) to the Kubernetes API. That means, no basic authentication or client certificate can be used.
    • The OS is locked down and container optimized with a limited and read-only root filesystem with integrity checks. Integrity monitoring of the OS is enabled, to protect against rootkits and malware.
    • The service account that the Kubernetes nodes are using is restricted and will only have privileges to access cloud services it needs, such as Stackdriver for logging and monitoring. 

    The things you need to make sure you enable:

    • Enable secure boot to validate the authenticity of the OS and kernel modules. (If you decided not to use the default OS, then it might cause issues).

    Using the virtual trusted platform module (VTPM) to sign kernel images and the OS, means that authenticity can be established. It also guarantees that nothing has been tampered with, and kernel modules have not been replaced with ones containing malware or rootkits inside.

    • Enable intranode visibility so you can see the data flowing between pods and nodes.

    Making sure all traffic is logged and tracked between pods and nodes will help you identify any potential risks that may arise later on. This isn’t necessarily something you need to do for development, but, something you should do for production.

    • Put the Kubernetes API on a private network.

    • Put the node pool on a private network.

    • Provide a list of authorized networks that should be allowed to talk to the API.

    Making your nodes and Kubernetes API private means it isn’t subject to network scans that are happening all the time by bots, hackers and script kiddies.

    Putting it behind an internal network that you can only access through a VPN is also good, however, this is a much more involved process with GKE and isn’t as simple as a feature flag like the others. You can read about what is involved here.

    Securing Your Application Containers

    Again, Google enables some default features to get you started. However, there are still gaps that you will need to fill. 

    What do you get?

    • Managed certificates
    • Role Based Access Controls (RBAC)

    What you will want to enable:

    • Pod Security Policies. This is Beta and requires you to inform Google that you’re wanting to run the cluster creation in beta mode:

    • Network Policies.

    This sounds great, but what does it actually mean? Basically, some of these roles are split into two, one is for application development teams to own and the other is for the cluster administrator.

    Application Developer

    • Set network policies at an application level so you only allow the right level of access, i.e., AppA can talk to AppB but AppC can’t talk to either of them.
    • Have encryption to your service endpoint for your desired domain, i.e., https://www.mydomain.com.

    Kubernetes can be a bit of a learning curve, there are technologies that make it simpler in terms of dependencies such as helm, that will allow you to deploy application dependencies with pre-defined deployments. But there is no real substitute from understanding the main components of Kubernetes;  Network Policies, Ingress, Certificate Management,  Deployment, Configmaps, Secrets and Service resources.

    The main security components are network policies, secrets and certificate management. Network policies will allow you to control the traffic to and from your applications. Secrets are base64 encoded, so there is no real security in terms of how they are stored; therefore making sure the cluster administrator has enabled secret encryption, (as mentioned further down), will add that additional layer.

    Certificate management will make sure the traffic to your service is encrypted, but if you’re communicating between services, then you should also add TLS between your applications. Having the cluster administrator install something like cert manager, will allow an easier way to encrypt between services. There are also services like Istio, but as that product does a lot more than just certificates, it can add more complexity than necessary.

    Cluster Administrator

    • Have the ability to control what users can do and in what namespaces (RBAC), i.e., maybe Bob the developer can do deployments, (create, update, delete), but can’t view secrets in namespace our-teams-app1-dev.
    • Implement a deny all network policy for both egress and ingress (outbound and inbound). This can be controversial, as it can catch teams out, so making sure you’re communicating this is key. It will, however, force teams to define network policies to get their application working.
    • Force an application deployment security stance with Pod Security Policies. This means preventing containers running in the cluster escalating privilege, mounting in devices (including binding to the host network) on the nodes or running more privileged kernel system calls.

    You want to make sure that development teams can’t deploy insecure applications or make attempts to escalate their privilege, mount in devices they shouldn’t or make unnecessary kernel system calls. Pod Security Policies offer a way to restrict how users, teams or service accounts can deploy applications into the cluster, enforcing a good security posture.

    RBACs and Pod Security Policies go hand in hand. Once you define a good Pod Security Policy, you then have to create a role that references it and then bind a user, group and/or service account to it, either cluster wide or at a namespace level.

    Note: GKE uses a webhook for RBAC that will bypass Kubernetes first. This means that if you are an administrator inside of Google Cloud Identity Access Management (IAM), it will always make you a cluster admin, so you could recover from accidental lock-outs. This is abstracted away inside the control plane and is managed by GKE itself.

    We recommend the below to be a good PSP.  This will make sure that users, service accounts or groups can only deploy containers that meet the criteria below.

    If you wanted to create a role to use the defined PSP above, then it would look like something below, this is a cluster role as opposed to a standard role. To then make this enforced on say all authenticated users, you would then create a role binding to apply to the “system:authenticated” group.

    Remember that as this is cluster wide, any applications that may need more privileged permissions will stop working, some of these will be things Google adds into kubernetes; such as kube-proxy, that runs in the kube-system namespace.

    You can read more information on RBAC and PSP’s on kubernetes.io.

    Securing Sensitive Data and Application Cloud Services

    We’ll break this down into two.

    1. Encrypting Your Secrets in Kubernetes

    The recommendation for encrypting secrets using Google Clouds KMS service, is to have segregated roles and responsibilities, and to define a new Google project outside of the Google project that will host Kubernetes and applications. This is to make sure the encryption keys and, more importantly, the key that is signing the other keys (envelope encryption) isn’t residing in the same project that could potentially get compromised.

    For encrypting secrets you need to:

    • Setup a new Google project to implement segregation of duties (if necessary).
    • Create the master key ring and key inside that project.
    • Only allow the GKE service account in the Kubernetes hosted project access to the key in the dedicated key project.
    • Only allow just the right permissions (encrypt and decrypt) of the service account.

    The documentation on how to do this can be found here. But the main things to remember are:

    • The key has to be in the same location (zone) as the cluster (this is to reduce latency or loss of a zone).
    • Access permissions have to be correct for the service account.
    • The binding is a KMS IAM policy binding.

    Once this is setup you can pass the path to the key, to the “gcloud container clusters create” command:

    Note: If any of the above is incorrect, you will get a 500 internal server error when you go to create a cluster. This could be the path is incorrect, the location is wrong or the permissions are not right.

    2. Consuming Cloud Service Inside of Kubernetes

    There are four different ways to allow application containers to consume cloud services. All of these have limitations in some way, i.e., being less user friendly and unautomated for developers (making developers wait for the relevant access to be provisioned), or have less visibility and more complexity in tying together auditability for Kubernetes and cloud administrators.

    1. Workload identity (this is still in Beta and is the more long-term direction Google are going in): Require a constant process of managing google IAM as well as Kubernetes Service Accounts to tie them together. This means managing Google IAM roles, policies and service accounts for specific application service lines as well as Kubernetes Service Accounts. It does, however, improve auditability.
    2. Google Cloud Service Account keys stores as secrets inside Kubernetes namespaces (where the application will be living): Similar to the above, but without the binding. This means provisioning a service account and placing it as a secret inside of the applications namespace for it to consume natively. This has the downside of not having full auditability within Google Cloud and Kubernetes.
    3. Use something like Vault to broker between Cloud and Applications: Using Vault provides an abstraction to cloud and will generate short lived access keys to applications. However, there is still a secret required to be able to speak to the Vault service, hence, the permissions are still the same but just abstracted down one. It also disjoints audibility between Google Cloud and Kubernetes.
    4. Using the default service account node role of GKE: Much simpler and more developer friendly, but more risky. It would mean allowing applications to use the default node service account and modifying the role to cater for all the service policies applications would need, increasing the scope and capability of the node service account to most Google Cloud services.

    Having Good Visibility; Current and Historic

    Note: As of today, there is no access transparency on when Google accesses your Kubernetes cluster (Google Access Transparency). This could be problematic for a lot of organizations who want assurances around the providers data access.

    When the cluster is provisioned, all audit logs and monitoring data is being pushed to Stackdriver. As the control plane is managed by Google, you don’t get to override or modify the audit format, log or extend it to your own webhook.

    It does mean that you can search your audit logs for things that are happening inside of Kubernetes in one place, for example; to query all events against a cluster inside of a specific Google project against your user ID, you can do the below:

    From this point on, you could take it further and add additional security rules such as setting custom metrics to alert when cluster admin changes are made or specific modifications are happening on roles (cluster-admin roles).

    Summary

    Security is something everyone wants but, as you can see, it can be quite an involved process to achieve. It also requires domain knowledge to get enough context to assess the risk and what it might mean to your applications and business.

    Security without automation can slow down productivity. Not enough security can put your business at risk. Enabling security features that require Beta feature enablement may also not be suitable for the business and only General Availability features are acceptable, which compromises on security.

    As a general rule, hardening your clusters and enforcing secure ways of working with Kubernetes, containers, cloud services and your applications will get you the best outcome in the end. There may be frustrating learning curves, but as the industry matures, these will slowly be remediated.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon EU, in Amsterdam. The CNCF has made the decision to postpone the event (originally set for March 30 to April 2, 2020) to instead be held in July or August 2020.

    — Lewis Marshall

  • Data Theorem Delivers Advanced API Security through Google Cloud Marketplace

    Data Theorem’s API Security Solutions Give Customers Ability to Uniquely Automate Continuous API Security Analysis and Vulnerability Inspection on Google Cloud Platform

    PALO ALTO, Calif., March 24, 2020 – Data Theorem, Inc., a leading provider of modern application security, today announced its availability on Google Cloud Marketplace (GCP Marketplace), providing customers with differentiated API security solutions that enable them to uniquely automate continuous API security analysis and vulnerability inspection on Google Cloud.

    Google Cloud Marketplace lets users quickly deploy functional software packages that run on Google Cloud Platform. Google Cloud Marketplace allows customers to easily start up a familiar software package with services such as Compute Engine or Cloud Storage, with no manual configuration required.

    Data Theorem delivers API Discover and API Inspect, which address security concerns such as shadow APIs, serverless applications, and API gateway cross-check validation by conducting continuous security assessments on API authentication, authorization, encryption, availability, cloud storage, databases, serverless functions, and policy compliance. The API security solutions discover modern APIs; enumerate the specification using standards such as Swagger and Open API 3.0; and support Amazon Web Services, Google Cloud, and Microsoft Azure platforms.

    “We are pleased to have Data Theorem’s solution available on the Google Cloud Marketplace,” said Manvinder Singh, Director, Partnerships at Google Cloud. “With just a few clicks, customers can leverage its capabilities to automate continuous API security analysis and vulnerability inspection.”

    “With built-in integration on Google Cloud, customers can quickly onboard, trial and enable continuous API discovery and security analysis of their applications and microservices built on Google Cloud,” said Doug Dooley, COO at Data Theorem. “Additionally, Google Cloud customers now have access to Data Theorem’s API security products to uncover leaky APIs, cloud security posture management (CSPM), compliance violations, policy enforcement, and auto remediation to fix vulnerabilities.”

    Availability and Pricing

    Data Theorem’s API security solutions are available today on the GCP Marketplace at https://console.cloud.google.com/marketplace/details/datatheorem-public/api-discover-and-inspect for a free 30-day trial with a GCP account.

    About Data Theorem

    Data Theorem is a leading provider of modern application security. Its core mission is to analyze and secure any modern application anytime, anywhere. The Data Theorem Analyzer Engine continuously scans APIs and mobile applications in search of security flaws and data privacy gaps. Data Theorem products help organizations build safer applications that maximize data security and brand protection. The company has detected more than 300 million application eavesdropping incidents and currently secures more than 4,000 modern applications for its enterprise customers around the world. Data Theorem is headquartered in Palo Alto, Calif., with offices in New York and Paris. For more information visit www.datatheorem.com.

    ###

    Data Theorem and TrustKit are trademarks of Data Theorem, Inc.  All other trademarks are the property of their respective owners.

     

  • InfluxData announces availability of the leading time series platform on Google Cloud

    The strategic partnership empowers Google Cloud customers with InfluxDB Cloud for powerful analysis of high volumes of time-sensitive data

    SAN FRANCISCO — February 4, 2020 — InfluxData, creator of the time series database InfluxDB, today announced the availability of InfluxDB Cloud on Google Cloud. The strategic collaboration, originally announced in April 2019, is part of a major Google Cloud initiative to make the most powerful open source technologies more accessible to its customer base. InfluxDB Cloud on Google Cloud delivers the leading time series platform to developers and businesses, with unified billing, support and integration with other Google Cloud services, such as BigTable, PubSub and Stackdriver.

    InfluxDB Cloud on Google Cloud is a serverless, purpose-built time series database-as-a-service with advanced analytics that provide real-time observability into IoT and DevOps workloads. Modern application development requires specialized tools to drive faster, more agile innovation, and general-purpose databases — both relational and non-relational — can’t handle the scale of these workloads in a cost-effective manner. InfluxDB Cloud empowers users to derive new insights from their data, and with usage-based pricing, ensures customers never have to worry about added costs of overprovisioning or risk their application being unavailable when they need it.

    “Data has gravity, and open source technologies are increasingly critical for building next-generation applications,” said Evan Kaplan, CEO of InfluxData. “Through this strategic partnership, Google Cloud is creating a marketplace for developers to thrive — with options for specialized workloads and access to the most powerful open source tools at their fingertips. It’s a continuation of our shared commitment to deliver solutions that help drive new data insights and applications.”

    “We began partnering with InfluxData with the goal of delivering best-in-class, open-source centric data solutions to customers,” said Manvinder Singh, Director, Partnerships at Google Cloud. “We’re delighted for InfluxDB to now be available for all customers on Google Cloud. Organizations can now leverage InfluxDB’s leading time series platform on Google Cloud, with unified billing and support, and integrations with key Google Cloud technologies.”

    The amount of data being produced worldwide is expected to grow nearly fivefold by 2025 to 175 zettabytes per year (IDC), driven by the proliferation of IoT sensors, serverless infrastructure, containerization and microservices. Most of this is time-stamped data generated at high frequencies and in great volumes that require rapid ingestion and real-time querying to extract maximum value.

    InfluxDB Cloud is the first and only serverless time series platform, and it is purpose-built to collect, store, query, process and visualize raw, high-precision, time-stamped data. With rapid ingestion rates (millions of metrics per second) and highly efficient compute, downsampling and compression functions, InfluxDB Cloud can perform up to 100x better than non-specialized time series solutions. InfluxDB Cloud features flexible and transparent usage-based pricing and a free tier to increase accessibility to all developers. InfluxDB Cloud leverages Flux, a new data scripting and query language that uses less code to extract more complex and valuable insights from data, better detect anomalies and enable real-time action with alerts and notifications.

    InfluxDB Cloud on Google Cloud is available now; learn how to get started on InfluxDB Cloud on Google Cloud for free at www.influxdata.com/products/influxdb-cloud.

    About InfluxData

    InfluxData is the creator of InfluxDB, the open source time series database. Our technology is purpose-built to handle the massive volumes of time-stamped data produced by IoT devices, applications, networks, containers and computers. We are on a mission to help developers and organizations, such as IBM, Visa, Siemens, Tesla and NASA, store and analyze real-time data, empowering them to build transformative monitoring, analytics, and IoT applications quicker and to scale. InfluxData is headquartered in San Francisco with a workforce distributed throughout the U.S. and across Europe. For more information, visit www.influxdata.com and follow us @InfluxDB.

     

  • DevOps Chat: Monitoring Spinnaker on GKE with Miles Matthias

    DevOps Chat: Monitoring Spinnaker on GKE with Miles Matthias

    On a project to move one of Google’s Fortune 500 customers to Google Cloud, Google Kubernetes Engine (GKE) and Spinnaker open source, our DevOps Chat guest ran into the message “hang tight.” No scripts or documentation. Not to be delayed, Miles Matthias, Google Cloud Consultant with Container Heroes, filled the gap and contributed his work back to the Spinnaker community.

    This episode of DevOps Chats features a preview of Mile’s talk, “Monitoring Spinnaker with Prometheus Operator on GKE” that he will be giving on Saturday, November 16th, 3:45 pm PT, at Spinnaker Summit 2019. Miles also talks quite a bit about Canary testing in this episode.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Miles Matthias, he’s a Google Cloud consultant and he’s with Container Heroes—great company name. Our topic today is actually a preview of his talk at the Spinnaker Summit 2019. His topic is gonna be Monitoring Spinnaker with Prometheus Operator in a GKE Environment, Google Kubernetes Engine. His talk is on Saturday, November 16th at 3:45. Miles, welcome to DevOps Chat.

    Matthias: Hey, Mitch. Great to be here. I’m really excited about the Spinnaker Summit.

    Ashley: Well, tell us a little bit about you, what you do and a little bit about Container Heroes.

    Matthias: Yeah, sure. So, like you said, at Crowd Consultant, I’ve done a whole bunch of software development and infrastructure setup and architecture design throughout my career and now I’m helping other companies set up their cloud infrastructure, make migrations, modernize their application development and all sorts of things like that. And I’m a partner at ContainerHeroes.com, and we’re a group of kind of people like me that have been in previous startups, CTOs, who’ve done the whole PC route, we’ve built a bunch of custom applications for clients throughout out career and now we enjoy consulting people that are using the cloud.

    For the past year or so, especially I guess the last nine months or so, one of our big clients, we’ve been helping Google with one of their new customers that was complete on prem to cloud, to Kubernetes containerization migration and they utilized Spinnaker. So, I kinda was brought in as the Spinnaker expert to help them get it up and running, to help customize what they needed in their environment and contributed as much as they could back to the open source, including some stuff that I built for using Prometheus Operator, which we can touch on a bit. And so much so that then the team invited me to give a talk at the conference, so I’m excited about it.

    Ashley: Sounds like a very—very relevant talk, especially sharing your experience from working with this Google customer.

    Matthias: Yeah.

    Ashley: So, tell us a little bit about when you came to this project and first started working with the customer. Had you worked with Spinnaker before, was that a new technology, or were any of these new technologies, or you’ve kinda done all this before?

    Matthias: So, I’ve done a bunch of CI/CD before. Spinnaker is still in its early days, so I have very limited experience with Spinnaker as an application. It’s still—yeah, it’s still very nascent on the development scene. The entire kinda concept of continuous delivery is still very new in the industry, even though it’s been around for a little while.

    And so, CI has been very well developed, everybody knows Jenkins, everybody has ____, a million CI tools, content of continuous delivery and having more thought out, sophisticated delivery strategies that can help you do more automated continuous delivery like canary analysis and different deployment types and automated rollbacks and all these sorts of things are kind of brand new and Spinnaker obviously really helps with a lot of that stuff.

    Yeah, I had some experience, but was really excited to jump in and kinda get into something that’s really taking off in the industry.

    Ashley: Tell us a little bit about the app that you were challenged to work on. I understand this was already, had been developed with Jenkins and Spinnaker before and then you were moving it to GKE, or what was it?

    Matthias: No. So, the client had 50 different job applications, a bunch of different things, and it was all running on prem. So, part of the big effort was to obviously move them onto Google Cloud, but also to help them develop a CI/CD process that allowed them to make a commit in their repo, have artifacts be built in CI, have tests run and then have those passed to Spinnaker and CD and then deployed to GCP.

    They had no experience with Spinnaker and didn’t have any kind of CD solution setup, really, especially for the cloud. Like I said, they were completely new to the cloud, so this is all new stuff for them, so I helped them set it up, install it, configure the options all we wanted, manage it and then introduce more and more advanced features as the project got more and more migrated over to GCP.

    Ashley: Mm-hmm. So, it sounds like maybe a more traditional Java application environment maybe is not even continuous integration yet. Were they down the path with that?

    Matthias: Yeah, they had Jenkins on prem.

    Ashley: They did?

    Matthias: And so we—you know, yeah. So, the architecture was moving everything to Kubernetes and so, you know, one of the GCP projects has GKE cluster just for CI/CD. So, running Jenkins and running Spinnaker on it. So, they had Jenkins on prem, and moved that over to the cloud, hosted it on Kubernetes, and then we installed Spinnaker right alongside it on the same GKE cluster, right?

    Ashley: Mm-hmm.

    Matthias: And then used those tools as the basis of their CI/CD pipelines to deploy to other clusters within the cloud for them.

    Ashley: How about the size of the application? How would you quantify how kind of big or extensive it was?

    Matthias: Like I said, they had a—this was a true microservices organization. So, you know, they have 30 to 50 different applications as microservices, each individually being deployed. As far as traffic, I mean, so the applications, like I said, are microservices, so they’re pretty small in and of themselves individually.

    As far as traffic and resource usage, it’s a very, very large, large client. Like, pushing the boundaries of some of the largest things we’ve seen.

    Ashley: Hmm. Okay.

    Matthias: So, that was really exciting—really cool.

    Ashley: This was a Fortune 500 company, I understand.

    Matthias: Yeah.

    Ashley: We’re not talking about the specific company, but—

    Matthias: Sure, yeah, yeah, yeah.

    Ashley: Well, good. Well, what are the sort of things that you’re planning on talking about, then? I mean, I know this is about the monitoring aspect of it, so you know, are you touching on Prometheus Operator and probably how to configure it or how you decide it and what kinds of groupings to create, what kind of rules and alerts and those kind of things? Are you gonna be talking more fundamental architecture? What are your thoughts?

    Matthias: Kind of a bit on everything, because this kind of—this is kind of some required setup in order to do monitoring and in order to do canary analysis, even, if you’re gonna use Prometheus for canary analysis metrics. And it’s also just fundamental to how you wanna have this setup if you’re running Spinnaker on Kubernetes in general.

    So, a little background on Spinnaker as a project, which I’m sure other people that are familiar with Spinnaker definitely know, you probably know yourself. Spinnaker was originally created by Netflix. Netflix is still very much a VM shop, right? So, they don’t use Kubernetes, and everything runs on individual instances. And so, Spinnaker can be deployed to run on Kubernetes and that support is there, it has support to deploy applications to other Kubernetes clusters.

    But there are still a few things like monitoring, like canary analysis where, in the Kubernetes world, we do things a little differently, and Prometheus is one of those examples, right? In the VM world, you spin up Spinnaker, you spin up one Prometheus instance—and Prometheus obviously is a metric store to collect metrics and then usually is paired with Grafana and ____ and things like that in order to—all CNCF open source projects in order to give you graphs on these metrics.

    And so, there was previously, in the VM world of Spinnaker, running it as Netflix does, a microservice of Spinnaker that does monitoring, that connects to all of the different components of Spinnaker, listens for their metrics and then reports it to Prometheus. Cool. Like, it looks great. They even have some dashboards.

    So, Grafana dashboards, if you’ve ever worked with those you can just upload some JSON files for your dashboard and then you click there and then you’re like, “Hey, look at these dashboards!” You can get real time dashboards based on the Prometheus metrics of Spinnaker. And Spinnaker, all the different components that it’s made up of and the different metric based on the things that it’s doing so that you can see in there when it’s processing your deployment, here are some of the metrics that are coming off, right?

    Ashley: Mm-hmm.

    Matthias: So, all of that support was there. When you want to run Spinnaker on Kubernetes, though, that support was a little…not so much. [Laughter]

    Ashley: Mm-hmm.

    Matthias: And that’s the trouble that we kinda ran into. So, the thing that was there was the concept of, “Hey, we have this monitoring component in Spinnaker,” and if you enable monitoring, that monitoring component will be enabled as a sidecar container to every single pod, every single microservice that Spinnaker is composed of, and it knows how to talk to that microservice and get the metrics from it and then report it somewhere.

    Cool—good. Okay, I can get that. What about the monitoring service then having those metrics that are just collected from all the different components and putting it somewhere? Ideally Prometheus, you can also do Stackdriver or, I believe there might be Datadog support now, but mainly, the two that we see used a lot, Stackdriver and Prometheus.

    Ashley: Mm-hmm.

    Matthias: However, in the Kubernetes world again, especially when you have a bunch of different Kubernetes clusters, one of the tools that you end up using is called Prometheus Operator. And that is essentially a Kubernetes operator that, when you apply to your cluster, will automatically install for you Prometheus Grafana, an alert manager as pods, deployments running on your cluster. It’s a way to provision your infrastructure so that when you deploy a bunch of applications in these clusters, you already have some monitoring infrastructure set up, right? I can deploy and I can basically go to my organization and say, “Give me a new cluster and then I can deploy my application and start admitting Prometheus metrics and there’s already a Prometheus instance on the cluster, so like, I’m good to go.”

    In order to get the Prometheus, the version of Prometheus that the Prometheus operator creates to then go and fetch the metrics from the Spinnaker monitoring component that already existed and already knows how to get those metrics from the Spinnaker different components, you have to kinda connect those two ends, right? And in the Prometheus Operator, the Kubernetes world, basically, you just apply Kubernetes manifest, the CRD called the Service Monitor, and that basically tells your instance of Prometheus on the cluster, “Hey, go fetch the metrics from these places,” right? And so, it’s pretty easy, but there was no setup way in Spinnaker. So, you would read the documentation in Spinnaker and they would have very detailed, very nice—like, if you’re running Spinnaker on VMs and you want to do monitoring and you wanna use Prometheus, just use this fancy and nice, easy setup script, right?

    Ashley: Mm-hmm.

    Matthias: Super nice. Great. And then literally in the documentation, it said, “If you’re running on Kubernetes. Hang tight, support is coming.” [Laughter]

    Ashley: [Laughter] The “hang tight” documentation feature. Wonderful!

    Matthias: Hang tight—yeah, right. So, none of this is extremely complicated. There are a lot of different components and you have to be careful about how you set them up, right? But the very nice setup script that was available for just running plain old Prometheus on VMs was very nice and like I said, it installed a bunch of Grafana dashboards for you and did a bunch of nice stuff for you. There was no such thing for Kubernetes, right?

    Ashley: Mm-hmm, mm-hmm. Kinda starting from scratch. Not completely, but at least to take that next step.

    Matthias: Exactly, exactly, exactly. And so, what I did and what I contributed to the project was creating a setup script for this exactly, saying, “Hey, you’ve got a cluster, you’ve got Spinnaker already installed on there, you’ve got Prometheus Operator installed on there and you’ve got a Prometheus Operator installed on probably a bunch of other clusters, too. Here’s a setup script that connects Prometheus instance to Spinnaker so that Prometheus can go and fetch those metrics about how Spinnaker is running and how Spinnaker is handling your deployments.”

    Ashley: Mm-hmm.

    Matthias: And installs a bunch of these Grafana dashboards that the open source project has already created for us to be able to say, “Here’s a Grafana dashboard about each microservice—Clouddriver, Gate, Orca, all the others, they each have their own dashboard in Grafana that you can go look at and they’re preconfigured and it’s really nice, it’s really neat.” Again, those just had to be kind of converted into the way you apply these in the Prometheus Operator world which, again, is applying your Kubernetes manifest to say, “Hey, it’s actually just a config map with a certain label on it.” “Hey, here’s a dashboard,” and when you apply that, the Prometheus Operator knows how to hook into the Kubernetes master and goes, “Hey, there’s a new config map that is a Grafana dashboard. Let me go fetch it and add it to Grafana for you,” right? That’s the whole purpose of Prometheus Operator.

    So, that’s kind of the thing that I set up was saying, was giving you—so now, and then I PR it to the documentation. So, now, when you go look at the documentation, it says, “Hey, if you’re running Spinnaker and Prometheus Operator on Kubernetes, there’s also a fancy setup script for you, too!” [Laughter]

    Ashley: There you go. Now people will have to start at the same place you did.

    Matthias: Yeah, really.

    Ashley: So, are your planning, on your talk, actually walking through this, the process of the script you built and how to set all this up, get the dashboards to come up, et cetera, or you’ve kinda taken a little different approach?

    Matthias: I don’t want to anger the demo gods, so I’m not sure if I’ll actually be, you know, typing it, running the actual scripts, but I can certainly have something set up that’s like, “Hey, this is the end result. Let’s step through what the script is actually doing to help you understand what components need to be matched up where, and then here’s the end result,” right?

    The other kinda couple things that I’ll probably touch on in the talk are—which is why it’s important. So, all of that is monitoring Spinnaker as an application. So, like, your DevOps or your Release Engineering team, people that are involved in these things who are gonna monitor Spinnaker as an application and are gonna see, “Oh, Orca is overwhelmed and it has a bunch of tasks in its queue that it can’t pop off, so let’s add some more replicas of Orca” or something like that.

    That’s what this script helps you set up is this dashboard to see the performance, to see those metrics, right?

    Ashley: Mm-hmm, mm-hmm.

    Matthias: And other reasons that it’s important are, and the other things I’ll touch on—well, first of all, the one thing I’ll probably touch on is that there’s kind of an effort currently in the works and I hope by the time of the talk, maybe there’s a little more effort built towards it, but there isn’t really a whole lot of guidance in the Spinnaker community about, “Okay, here are the metrics we emit. Here’s what they mean, and if they go outside normal ranges, here’s what you should do to remedy that situation.”

    Ashley: Mm-hmm.

    Matthias: There are no kind of run books, as you might call them, for how to respond to a Spinnaker instance that is under a really extreme load or kinda gone configure sideways or something like that.

    Ashley: Interesting.

    Matthias: Rob Zyner kinda leads the Netflix effort. He’s done a great blog post about some of the metrics and things like that and what each of them mean. But that’s kind of the only resource out there. So, there is kind of this effort in the community to say, “Hey, let’s put together some actual run book and match some of these dashboards that we have in Grafana and some of these metrics and be able to tell people, ‘Hey, if you run into this situation, here are the step 1, 2, 3 to check, and if these are the case, then here are the three options for alleviate that problem or how to address the problem,” right?

    Ashley: Mm-hmm.

    Matthias: So, hopefully, by the talk in November, we might have some progress on that in the community.

    The other thing that I’ll probably talk about on the topic and why the concept of the Prometheus Operator is so important in the Kubernetes world is for canarying.

    Ashley: Say a little bit about what canarying is with your deployment processes.

    Matthias: Yeah, sure. Sure, so, canary testing is—it’s a form of testing that evaluates one of your release candidates. It compares it to—what it does is, it actually runs your candidate, and it runs the version that is running in production, starts a new copy of it, and it runs it side by side. So, then it is—and then it diverts usually a small amount of traffic or just, you know, will have 100 pods behind a service and you’ll add 2 pods so they’ll get a proportional small amount of traffic. And you’ll run it and you’ll see how it performs. You’ll listen to the metrics and you’ll see, “Oh, this is how your candidate that you want to push performed.” And in canarying, in the configurations in Spinnaker, you can say, “These are the metrics I care about when evaluating, when deciding if it performed well and if it performed badly.”

    For instance, let’s say you have a new version of the application that just, like, 500—500 errors out on every request, right? You run a bunch of unit tests, you run a bunch of integration tests and ideally, at that point, at one of those steps or earlier, you would’ve caught that, right? But tests are written by people and sometimes people don’t write them or sometimes some situation that depends on live traffic and live data actually exposes some types of problems, right?

    So, let’s hypothetically pretend you have a new version that comes out and it’s just 500s all over the place. What canarying says, the kind of theory behind it is—let’s actually run it on a small amount of traffic, let’s see what it does. And then canarying would go, “Oh, hey, your release version that you wanna push out? It’s just doing a bunch of 500s, and you told me in your configuration, if you see so many, a spike in 500s, that that’s bad, that we don’t wanna actually then deploy that to all 100 instances running in production,” right?

    That canarying says, “Hey, that’s not a good thing to promote,” right? Like, “I gave it a chance, I ran it on some things, I compared it to what the version that is currently running or our new instance of the version that’s currently running, and it didn’t do well. So, you know what? I’m gonna error out, I’m gonna show you this is how it behaved, you guys go fix it, and then when I come back, I’ll run those things again. And if it performs well, then great, we can release the new version.”

    And that’s kind of one of the main components that you need for continuous delivery. Because you can imagine a world where developers are just committing, committing, committing, committing.

    Ashley: Well, yeah.

    Matthias: They do a bunch of tests, they run some tests, to them it all looks good. And then you just have this other automatic component over here that’s doing canary analysis and that can just test it, it can actually put it into production, give it a little bit of traffic, see how it performs, and if it performs well, then let it go, you know? Promote it, right?

    Ashley: Yeah, that’s extremely useful.

    Matthias: Deploy on a Friday, deploy on a Saturday—who cares, right? It’s actually seeing how it’s running, all the other tests before it’s even gotten to that point have passed, obviously, and if it runs well, then run. And this is what enables organizations like Google, Netflix, and others to deploy thousands of times a day, because it has this automated system to go in and say, “Give it some traffic, see how it runs, and if it runs fine because of the way we configured how we told the system what does it mean to run fine, right? Great—then let it go.”

    Ashley: We’re kinda running up against our time, here. I do have one last question.

    Matthias: Sure.

    Ashley: What kind of folks should come to your talk? Obviously, it seems like developers, people who are working on the CI/CD pipeline, maybe DevOps engineers. Are there other folks you’d recommend, or are those the right folks?

    Matthias: Those are definitely all the right folks. I think if you’re interested in Spinnaker or you’re currently using Spinnaker where you are, want to know about monitoring it as an application and managing it as an application when it experiences a bunch of load and how you want to connect all the dots if you’re running it on Kubernetes and you’re running multiple other Kubernetes clusters that also are using Prometheus Operator, this is a great talk to go listen to.

    Ashley: Again, Miles is a Google Cloud Consultant with ContainerHeroes.com. He’s speaking at the Spinnaker Summit 2019 in San Diego. Now, that conference is the 15th through the 19th of November. His talk, again, is on monitoring Spinnaker with Prometheus Operator on GKE on Saturday the 16th at 3:45. Thank you, everyone, for joining us. You’ve listened to another DevOps Chat. This is Mitch Ashley with devopsy.kinsta.cloud. Be careful out there.

    — Mitchell Ashley

  • Logz.io Unveils Azure Open Source ELK Monitoring Solution

    Logz.io Unveils Azure Open Source ELK Monitoring Solution

    Needless to say, DevOps as a practice is largely fueled by open source. The growth and popularity of open source tools such as Elasticsearch, Kubernetes and others are driven largely by the increased flexibility, innovation and familiarity of options. While this isn’t news for developers (65% of which are active open source contributors), leading cloud providers are taking notice, as they try to increase their appeal to DevOps engineers to finally win the cloud wars.

    Currently, AWS is the leading cloud provider. However, with Azure gaining more and more momentum, all three major cloud providers are scrambling to offer their customers the best open source options and empower them to use the tools they know and love in a manner that is convenient and native to their cloud environments.

    Going Big on Open Source

    Today, Logz.io and Microsoft Azure announced that our ELK-as-a-service will now be offered on Microsoft Azure. Logz.io offers an intelligent machine data analytics platform built on ELK and Grafana, two of the most popular open source monitoring and troubleshooting tools. Our platform enables engineers to easily deploy, run and scale ELK without the hassle and pain of maintaining and managing the stack themselves.

    Now, with Logz.io for Azure, users can use open source ELK as a highly integrated experience in Azure. The new offering includes seamless integrations to various Azure services, out-of-the-box Azure dashboards, built-in alerting and crowdsourced machine learning capabilities.

    The integration between Logz.io and Azure is not only significant in the context of the cloud wars, but in the culture of Microsoft itself. While the company was previously associated with a more proprietary structure, they have made tremendous strides in recent years toward empowering open source by opening its .NET framework and Azure SDK, as well as their acquisition of GitHub.

    According to Julia Liuson, corporate vice president of Microsoft’s developer division: “At Microsoft, we see open source as a major driver of innovation within the engineering community. Since we strive to empower our customers and facilitate their success, it is important to us to meet them where they are by making it easy to access and use open source tools. Our partnership with Logz.io will strengthen Microsoft Azure ties with the developer community, enabling teams to easily build and monitor their products using ELK.”

    AWS vs. Google Cloud

    Microsoft’s investment in ELK  comes just in time to provide an answer to its competitors, AWS and Google Cloud. Just two months ago, AWS announced Open Distro for Elasticsearch, which in their own words “is a value-added distribution of Elasticsearch that is 100% open source (Apache 2.0 license) and supported by AWS.” The new offering includes managed Elasticsearch and Kibana along with features such as built-in alerting, security and more. This was AWS’ most recent appeal to the engineering community, offering one of the most popular monitoring tools as a managed service on AWS.

    Following this release, Google Cloud announced its own open source offering featuring integrations with leading companies such as Elastic, MongoDB, Confluent and more. According to Google, the purpose of  these integrations was to “provide users with a seamless user experience and the ability to easily leverage these open-source technologies in Google’s cloud.”

    Is Open Source the Future?

    If what’s happening between cloud vendors is any indication of future trends in the engineering space, it seems imperative that all organizations targeting DevOps teams must consider how they’ll fuel open source and empower its vast user community. At Logz.io, we are proud to be part of this initiative.

    Overall, it is great to see the strides large organizations are taking in furthering the interests of the developer community and enabling them to work using the tools, methodologies and strategies that best suit their workflows and ideals.

    — Daniel Berman

  • The Biggest News from Google Cloud Next ’19? Better Capabilities for Big Data

    The Biggest News from Google Cloud Next ’19? Better Capabilities for Big Data

    Data analytics is about to become a whole lot easier. Google’s annual Google Cloud Next conference brought plenty of new announcements and innovations. But the search giant’s focus on data has stolen the show. Partners of the tech titan such as Fivetran, DataStax and Hammerspace are bringing unprecedented data capabilities to the Google Cloud Platform (GCP).

    Accelerated Data Analytics = Automated Data Infrastructure

    When Google BigQuery came onto the scene, it changed data analytics forever. Acting as a serverless and scalable data warehouse, the service unlocked unparalleled price-performance and productivity for enterprises around the world.

    Now, Google aims to simplify things even more with BigQuery Data Transfer Service, a new offering that lets organizations automate data movement from SaaS applications to Google BigQuery on a scheduled basis. Basically, you can build a robust and dynamic data warehouse without having to write any code.

    Fivetran, a startup that lets you automate data infrastructure into your warehouse for advanced analytics, is one of Google DTS’ launch partners. The company has built a solid reputation around its prebuilt, maintenance-free data connectors; you can deploy them in five minutes and completely replicate applications, databases and more.

    Without leaving the Google Cloud environment, users can automate setup and product integration between Google Cloud and Fivetran. This allows them to drastically reduce overhead maintenance when centralizing disparate data sources. In turn, this accelerates analytics and reduces time to insight.

    Currently, Fivetran and Google Cloud offer connectors for more than 100 sources, including NetSuite, Salesforce, Marketo and more. Fivetran is currently developing new data connectors, so you can expect this list to expand soon.

    A New Database-as-a-Service Offering

    DataStax is a company and GCP partner that delivers “Active Everywhere,” distributed cloud databases to support always-on, web-scale applications. It has roughly 400 customers across 50 countries.

    The company’s CEO, Billy Bosworth, realized that its clients needed more flexibility in moving data among public and private clouds. So, for the first time ever, it’s now providing a database-as-a-service (DBaaS) offering.

    Bosworth explains the demand: “Recently, enterprise customers have said they want those database attributes available to them in a variety of on-premises and cloud options—or in other words, for their hybrid cloud and multi-cloud realities.”

    The new agreement with Google Cloud to offer DataStax Enterprise as a DBaaS will do just that—and more. Not only is the new service the first major step in making this wish a reality, it also will provide users with optimal flexibility in how and when data gets moved to public and private clouds.

    Hammerspace DaaS Arrives on GCP

    Fivetran and DataStax aren’t the only ones bringing new data management capabilities to GCP. Hammerspace, a Los Altos, California-based company, recently announced its new Data-as-a-Service (DaaS) platform has arrived on the GCP Marketplace.

    Hammerspace is dedicated to simplifying data consumption for hybrid cloud and container users. The company provides a global data workspace for organizations that is free from the usual lock-in that comes with storage silos.

    Since its cloud data control plane is both storage and protocol-agnostic, Hammerspace can abstract data from the infrastructure to provide self-service hybrid cloud data management. When combined with metadata management and machine learning, it allows the company to deliver its DaaS in which enterprises can make file data cloud-native. In turn, this allows them to automate only once and deploy anywhere.

    Hammerspace DaaS will let users protect and manage their data across hybrid cloud environments with global enterprise file data services. And with support for both GCP storage classes and on-premises storage, it will be easier than ever before for analytics teams, application owners and data operations to leverage their new service.

    What Will You Do With Your Data?

    With new data offerings from Fivetran, DataStax and Hammerspace, GCP is becoming the place to be for all data endeavors. But this is just the beginning; you can expect more announcements soon as Google continues to double down on more data tools to offer.

    For now, the only question left is this: What will your company do with these new data capabilities?

    — Ben Bloch

  • CloudBees Allies with Atos to Accelerate DevOps Adoption

    CloudBees Allies with Atos to Accelerate DevOps Adoption

    In a move that should accelerate adoption of best DevOps practices in the enterprise, CloudBees and Atos announced this week that the two are collaborating to advance adoption of continuous integration/continuous development (CI/CD) platforms on the Google public cloud.

    Announced at the Google Cloud Next 2019 conference, the alliance will result in the IT services giant delivering a managed instance of a CloudBees CI/CD platform running on the Google cloud, in addition to providing traditional consulting services.

    Francois Dechery, chief strategy officer for CloudBees, said the alliance with Atos will accelerate adoption of DevOps processes in traditional enterprise IT organizations as Atos consultants engage customers looking to modernize their application development and deployment processes. In fact, many of the principles first pioneered by proponents of agile development methodologies are now being applied to business process management, he noted.

    Atos plans to add a DevOps practice as a complement to its existing processes. Michael Kollar, senior vice president for cloud engineering, said the company expects that, for the foreseeable future, most of their clients will be trying to meld some degree of DevOps and existing ITIL-based approaches to IT services management (ITSM). The alliance with Google will go a long way to accelerating that transition because it will allow Atos to deliver access to a CI/CD platform based on a consumption model that reflects the way public cloud infrastructure is consumed, he said.

    Kollar noted enterprise IT organizations are under more pressure than ever to deliver applications faster as more organizations recognize they are a software company that happens to make something. Most organizations today need to create a superior customer experience through software to differentiate themselves from their competition, he said.

    Many of those companies will need help setting up the processes that will enable them to function as a software company, he added. The biggest challenge, however, is finding a way to meld new ways of building and deploying applications with investments in legacy systems on which the business still depends, he said.

    Naturally, Atos won’t be the only IT services firm to launch a managed DevOps process. But as more IT services firms invest in developing managed services, there will be need for a balance between the managed services provided by IT services providers and cloud service providers such as Google and the IT services that will continue to be managed and delivered by internal IT organizations. The degree to which organizations will rely on external IT services firms for DevOps will be dictated by how mature they are today. But it does not follow that an organization which sees a need to rely on external expertise today will be that position tomorrow. As more organizations develop internal expertise, a managed service provider will need to earn its seat at the table every time its contract comes up for renewal.

    — Mike Vizard

  • InfluxData Integrates with Google Cloud IoT Core to Improve Users’ IoT Environments with Expanded Data Collection and Analysis

    Google Cloud IoT Core now Includes Powerful Time Series Platform to Help Users Improve Operational Efficiency and Real-Time Decision Making from IoT Sensor Data

    LONDON (Google Cloud NEXT London) — Oct. 10, 2018 — InfluxData, the modern Open Source Platform built specifically for metrics, events and other time series data that empowers developers to build next-generation monitoring, analytics and IoT applications, today announced the availability of a new Telegraf agent for Google Cloud IoT Core. Now Google Cloud IoT Core users can get better insight and analytics from their IoT environments by using the leading time series database solution to provide continuous insight, improve operational efficiency, and better optimize their businesses with real-time decision making and control.

    Google Cloud IoT Core is a complete set of tools to connect, process, store, and analyze data both at the edge and in the cloud. InfluxData’s Telegraf is a plugin-driven server agent for collecting and reporting metrics and data. With this new Telegraf plugin, organizations can derive value by monitoring and tracking sensor data, using historical data from sensors to gain insights that can be applied to current situations (predictive maintenance, optimized traffic routing), and delivering automated action and control (such as shutting down a leaking water pump) with no human interaction. Google Cloud IoT Core can help customers maximize ROI of their IoT applications by capturing, understanding and acting on data collected from IoT devices and sensors in real time.

    “InfluxData’s ability to integrate with Google Cloud IoT Core enables us to address the time series data collection and analysis needs of IoT customers, and we are pleased to be a new contributing member to the Google Cloud IoT ecosystem,” said Sharjeel Noor, Senior Director, Platform & Partnerships at InfluxData. “This effort fits with our IoT strategy where we focus on being the data services platform of choice, and offer these benefits as a part of larger ecosystems, such as Google Cloud.”

    IoT ROI is only as good as the real-time data collected and available to be analyzed for real-time decision making. IoT data is time series data, and InfluxData delivers the leading Time Series Platform that ensures data is collected and analyzed in real-time. InfluxData provides the data services layer to Google Cloud IoT Core that allows users to collect time series data for instrumenting, observing, learning and automating any system.

    Since the Telegraf project’s inception, the majority of the 160 plugins available today have been built by the community and not InfluxData engineers, demonstrating the vibrant contributions from its community. Subject matter experts easily create new Telegraf plugins helping the community quickly collect a wider range of metrics. As a result, any updates to existing plugins or the introduction of new plugins are available to customers, including Google Cloud IoT Core customers, in real time to quickly gather custom metrics about their workloads. Google Cloud IoT Core customers can be up and running in a few hours to easily collect and store their IoT data in a purpose-built time series database within the Google Cloud IoT ecosystem for alerts, monitoring and real-time decision making.

    In addition, now Google Cloud users have one-click access to InfluxData’s Time Series Platform for collection and analysis of metrics and events data for real-time decision making through InfluxData’s new Google Cloud Platform (GCP) Marketplace listing at https://console.cloud.google.com/marketplace/details/influxdata-public/influxdb-enterprise-byol. Users can find simple one-click configuration available for the Telegraf-InfluxData-Grafana VM package. In the future, several popular one-click configurations such as the Prometheus-InfluxData-Grafana VM package are also planned for release. This furthers InfluxData’s mission to help developers get to results faster by providing automated provisioning mechanisms on their favorite cloud platform.

    InfluxData delivers a modern IoT data platform built from the ground up to support organizations looking to best leverage the wealth of IoT data delivered from their devices and sensors to provide an advantage for their customers. IoT data is unique in that sensors deliver time-stamped or time series data to measure change over time, the data is streamed relentlessly from sensors, and sensors capture and emit data in real time. With InfluxData, companies always have a direct view into the state of each of their devices and sensors so changes can be made to keep services running efficiently. Its InfluxDB database is the overwhelming leader among Time Series Database management systems, according to DB-Engines’ latest results.

    InfluxData has rapidly built its developer and customer base across industries – including manufacturing, financial services, energy, and telecommunications – by delivering the fastest growing Open Source Platform that enables customers to derive better business insights, data-driven real-time actions, and a consolidated single view of their entire infrastructure – from applications to microservices, and from systems to sensors. More than 420 customers, including Cisco Systems, Coupa Software, IBM, Houghton Mifflin Harcourt, Nordstrom, and Tesla have selected InfluxData as their modern data platform for metrics and events. InfluxData is pioneering the shift to time series in a modern metrics and events platform, and is making it possible for customers to become data-driven and take on digital transformation initiatives.

    About InfluxData

    InfluxData, the creator of InfluxDB, delivers a modern Open Source Platform built from the ground up for analyzing metrics and events (time series data) for DevOps and IoT applications. Whether the data comes from humans, sensors, or machines, InfluxData empowers developers to build next-generation monitoring, analytics, and IoT applications faster, more easily, and to scale delivering real business value quickly. Based in San Francisco, InfluxData’s more than 420 customers include Cisco, eBay, IBM and Siemens. Visit https://www.influxdata.com/. Twitter: @influxdb.

  • Evaluating a Multi-Cloud Strategy: The Pros and Cons

    Evaluating a Multi-Cloud Strategy: The Pros and Cons

    First off, let’s define multi-cloud. Clearly, we’re talking about using one or more clouds, but clouds come in different flavors. For example, multi-cloud incorporates the idea of hybrid cloud—a mix of public and private clouds. But multi-cloud can also mean two or more public clouds or two or more private clouds.

    So, why is this important? Over the past year or so, I’ve seen a major increase in the amount of companies who use multiple public clouds. In fact, more than 20 percent of ParkMyCloud’s customers use multiple public clouds. With this trend in mind, I think it is time to take a look at the positives of a multi-cloud strategy. But I also want to mention the negatives—because, of course, there’s no “easy button.”

    According to the “RightScale 2018 State of the Cloud Report,” more than 80% percent of enterprises have a multi-cloud strategy:

    What are the Advantages of Multi-Cloud?

    So, why are businesses heading in this direction with their infrastructure? Simple reasons include the following:

    • Risk mitigation—create resilient architectures.
    • Managing vendor lock-in—get price protection.
    • Optimization—place your workloads to optimize for cost and performance.
    • Cloud providers’ unique capabilities—take advantage of offerings in AI, IOT, machine learning and more.

    When I asked our CTO what he sees as the advantages of a multi-cloud strategy, he highlighted risk management. Our own platform was born in the cloud, so we run on AWS. We also have a multi-region architecture with redundancy (let’s call this “multi-cloud light”) and if we went multi-cloud, we would leverage another public cloud for risk mitigation.

    Specifically, he mentioned risk management from the perspective of one vendor having an infrastructure meltdown or attack. AWS had an issue about 15 months ago year when S3 was offline in US-East-1 region for more than five hours, affecting many companies large and small. Software from web apps to smartphones apps were affected (including ours). Certain AWS regions also have been the target of DDoS attacks that have affected service availability.

    Having a backup to another cloud service provider (CSP) or private cloud in these cases could have ensured 100 percent uptime. In the case of Alibaba and other cloud vendors, they may have a much stronger presence in certain geographic regions due to a long-term presence. When any vendor gets a toe-hold in a region, its environment has minimal redundancy and safeguards in place that provide the desired high availability; in this case, another provider in the same region may be safer from an availability perspective.

    What are the Disadvantages of Multi-Cloud?

    Now let’s say you want to go multi-cloud: What does this mean to you? From our own experience integrating with AWS, Azure and Google Cloud, we’ve seen that each cloud has its own set of interfaces and own challenges. It is not a “write once, run everywhere” situation between the vendors, and any cloud or network management utility system must do the work to provide deep integration with each CSP.

    Further, the nuances of configuring and managing each CSP require both broad and deep knowledge, and it is rare to find employees with the essential expertise for multiple clouds, so more staff is needed to manage multi-cloud with confidence that it is being done in a way that is both secure and highly available. With everyone trying to play catch-up with AWS—and with AWS itself evolving at a breakneck pace—it is very difficult for an individual or organization to best utilize one CSP, let alone multiple clouds.

    A common container environment, for example, can help mitigate these issues somewhat by isolating engineers from the nuances of virtual machine management; however, the issues of network, infrastructure, cost optimization, security and availability remain very CSP-specific.

    On paper, there are advantages of having a multi-cloud strategy. In practice—like many things—it’s not as easy as it may seem.

    — Jay Chapel

  • goPaddle goes Google Cloud and Kubernetes v1.2 friendly

    SEATTLE, March 18, 2016 /PRNewswire/ — Bluemeric Inc, a Cloud & DevOps company, today announced the release of the next version of goPaddle v2.0, a DevOps platform for micro-services.

    goPaddle optimised for Google Cloud and Kubernetes v1.2

    2016 being the year of DevOps, IT organizations are already looking at scale-out and economies of scale, while e-commerce companies have understood the impact of agile delivery and zero downtime of their applications. As Gartner predicted, it is becoming a mainstream strategy employed by 25 per cent of Global 2000 organisations. While the need for DevOps is building up, micro-services based architecture is becoming the key enabler for rapid application delivery. Micro-services are sizable units of execution that are independent, polyglot and reusable. Independent teams / developers can make versions of these micro-services, package them as container such as Docker and deploy them on an infrastructure of their choice. Container Clusters like Kubernetes provide a distributed and portable platform that can manage the lifecycle of these containers and provide consistent environments so that applications can be moved painlessly across datacenter and clouds.

    While a spectrum of DevOps ready solutions are emerging in the market, a platform that is focused on continuous build, integration and deployment for micro-services will be a huge cost & time saving solution for businesses.

    Customers have been using goPaddle, for continuous build and deployments since last year. With the new release, goPaddle is optimized for Google Cloud, thus making authentication, on-boarding micro-services and cluster provisioning simple and seamless for Google Cloud Developers. goPaddle provides a powerful yet simple designer interface, that developers can use to drag drop components to create micro-service designs and generate container/cluster specifications on the fly. These designs can then be deployed on to Google Container Engine (GKE) or to a cluster of their choice. Developers can leverage Google Container Registry (GCR) or use Docker Hub for storing/retrieving the container images. As these features signify, goPaddle has moved the infrastructure management hassles away from the developers, while the developers can focus on building their applications.

    While adding simplicity, goPaddle also gives the traceability and control to audit and monitor the applications. In general, log aggregation platforms like fluentd have greatly been in use by the developers and system administrators to monitor the system, application and access logs. goPaddle v2.0 brings in the support for fluentd leveraging the newest features in Kubernetes v1.2. With goPaddle, fluentd can be deployed on selective cluster infrastructure to aggregate logs from micro-services running within those infrastructure.

    goPaddle is available as a hosted version at https://gopaddle.io and as enterprise ready on-premise version with extended support. For more information, get in touch with the Bluemeric team at info@bluemeric.com.

    Photo – http://photos.prnewswire.com/prnh/20160317/345548