Category: DevOps in the Cloud

  • Microsoft Extends Azure Reach to On-Premises IT Environs

    Microsoft Extends Azure Reach to On-Premises IT Environs

    Microsoft today at its Ignite 2019 conference previewed an Azure Arc management service that extends the reach of the Microsoft cloud to on-premises IT deployments.

    Azure Arc will be made available on both local Windows and Linux servers as well as Kubernetes clusters or an instance of Kubernetes that Microsoft is making available on Azure Stack for on-premises IT environments. With these announcements, Microsoft is, for the first time, extending its hybrid cloud computing strategy beyond systems running a version of the Azure operating environment on an on-premises IT environment.

    Jason Zander, executive vice president for Microsoft Azure, told conference attendees Azure Arc creates an opportunity for IT organizations to extend the best DevOps and cloud management practices employed on Azure to on-premises IT environments. Rival cloud service providers, he noted, are only paying lip service to hybrid cloud computing.

    In addition to extending the Azure management plane to on-premises IT environments, Microsoft today extended its portfolio of edge computing platforms capable of running instances of Azure Stack to include previews of commercial series and rugged series for Azure Stack Edge. Configurable with graphical processor units and field-programmable gate arrays (FPGAs) capable of running machine learning algorithms in harsh environments, the ruggedized instance of Azure Stack Edge even includes a portable server designed to be carried in a backpack.

    To complement those systems, Microsoft is also previewing a range of additional services for Azure Stack, including a fully managed, real-time data ingestion service designed to stream millions of events per second from any source to build data pipelines the same way the company does on the Azure cloud; a cloud database management service for Microsoft SQL Server and Postgres; and an Arc-enabled application programming interface (API) management platform.

    While Microsoft generally would prefer organizations to adopt Azure Stack as an on-premises extension to Azure cloud, not many organizations have the robust modern server infrastructure in place required to run Azure Stack. Azure Arc is an effort to extend the reach of Azure to multiple types of edge computing platforms without requiring organizations to deploy yet another operating system. Alternatively, organizations can employ a diverse range of Kubernetes distributions, of which there are now more than 70 that have been certified by the Cloud Native Computing Foundation (CNCF). Most organizations at this stage have yet to standardize on a single distribution of Kubernetes.

    It’s unclear what the appetite is for extending the management plane Microsoft created for its Azure cloud to on-premises environments. However, as the scope of the hybrid cloud management challenge facing organizations grows as various new forms of edge computing manifest, Microsoft clearly sees an opportunity to increase the scope and reach of its cloud platform strategy. Each edge computing instance is essentially a smaller instance of a cloud platform for which most IT organizations will not have the tools required to manage at scale. In fact, many IT organizations might not even attempt to deploy workloads at all on those platforms without something equivalent to Azure Arc to manage and secure those environment first being in place.

    — Mike Vizard

  • New Relic Bolsters Serverless Monitoring Strategy

    New Relic Bolsters Serverless Monitoring Strategy

    New Relic has strengthened its ability to monitor serverless computing frameworks by acquiring IOpipe, a provider of a monitoring tool for the serverless computing framework service provided by Amazon Web Services (AWS).

    Andrew Tunall, general manager for serverless and emerging cloud services at New Relic, said IOpipe’s monitoring technology will be used to augment the monitoring tool for AWS Lambda included in the New Relic One platform, which was launched earlier this year.

    New Relic also plans to expand its observability capabilities for serverless computing to other platforms based on customer demand, said Tunall.

    Serverless computing frameworks are gaining traction because they enable developers to write less code within their applications by allowing them to employ functions to call on a cloud service to process, for example, analytics externally rather than within the application itself. The challenge serverless computing frameworks create from a DevOps perspective is they don’t create any logs that can be analyzed. Instead, monitoring tools need to be able to employ distributed tracing tools to analyze the streams of metadata that serverless computing frameworks create based on event-driven architectures. That requirement has forced providers of monitoring tools to extend the capabilities of their core platform to enable the consumption of that metadata.

    Adoption of serverless computing frameworks is already outpacing the ability of many DevOps teams to observe. According to AWS, hundreds of thousands of customers are already doing trillions of invocations a month of AWS Lambda. Gartner has predicted that by 2023, 100% of enterprises using IaaS or public cloud will also use some form of serverless platform-as-a-service (PaaS) capability in production applications, up from 25% in 2019. In most cases, those serverless computing frameworks will be employed to process stateless workloads, while stateful workloads continue to run on a virtual machine or within a container.

    While most of the usage of serverless computing frameworks thus far is on public clouds, it’s only a matter of time before organizations increasingly make use of multiple serverless computing frameworks in on-premises IT environments. There are already more than a dozen different types of serverless computing frameworks, most of which are being made available as open source projects.

    Naturally, the rise of serverless computing frameworks complicates DevOps even further. DevOps teams will now need to build, deploy and update applications that are making frequent external application programming interface (API) calls to potentially multiple serverless computing frameworks. Rather than requiring organizations to acquire separate tools to monitor serverless computing frameworks, New Relic is making a case for extending a single platform to monitor all the various types of IT platforms being employed.

    There’s almost no doubt most organizations will wind up invoking serverless computing frameworks in one fashion or another, but it’s too early to say how pervasive serverless computing frameworks will be. However, DevOps teams will be required to monitor those serverless computing frameworks alongside every other platform already being employed across an increasingly diverse IT environment.

    — Mike Vizard

  • A New Paradigm in Container Security with Service Mesh

    A New Paradigm in Container Security with Service Mesh

    Containers have been around for some time, but only recently has the technology become mature enough for large enterprises to adopt it both on-prem and in the cloud. The obvious benefits for developers include the ability to dramatically reduce the time to production and the ability to lower the operational burden. This is further supported by implementing a service mesh which provides fast, reliable and secure communication among containerized infrastructure.

    The Rise of Kubernetes and its Impact on Security

    Kubernetes (k8s), introduced late 2014, bring container orchestration at large scale to both cloud and on-prem environments. The benefits of using k8s is clear and stipulated mainly due to the ability to become agnostic to the infrastructure. An application based on k8s can easily scale out from your datacenter into multiple cloud providers, and back. However, the challenge with Kubernetes is it creates a huge problem for security operations. Trying to enforce micro-segmentation on a large k8s cluster using traditional firewall models is not feasible.

    As the move to containers rise, so will container-based cybersecurity attacks. Criminal hackers will always be on the hunt for new ways to exploit this area. As container operations are inherently dependent on the development pipeline (CI/CD) so should be their security attributes. Any other interaction point will be an afterthought resulting in slower operations or reduced security. Organizations moving to containers and k8s should act preemptively due to on-going and increasing complexity driven by scale.

    Enter Service-Mesh

    Implementing a service mesh layer ensures that communication among containerized infrastructure services is fast, reliable and secure. It is a configurable, low‑latency infrastructure layer that handles service-to-service communication. It is responsible for the reliable delivery of requests through the complex topology of services that make up a modern, cloud-native application. In practice, a service mesh is typically implemented as an array of lightweight network proxies called sidecars, that are deployed alongside application code without the application being aware. The mesh provides critical capabilities, including service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern.

    Criteria and Security Best Practices

    • Pre-scanning of images isn’t enough. Enforcing runtime micro-segmentation for container services should be addressed at runtime as they introduce an easier, more prominent attack vector.
    • Easy integration with development pipeline. As noted, the alternative will impact business agility or security quality.
    • Micro-segmentation should be decoupled from the infra and network as otherwise, it will require some kind of application to IP/PORT/protocol mapping.

    Implementing security built for k8s environments and running both on-prem and in the public cloud that uses Istio, a well-known open-source service mesh developed by Google, is recommended. Vet solutions connect directly to the code pipeline with enhanced security capabilities, such as the signing of artifacts that will be deployed to the k8s cluster in the code stage with the ability to generate signed identities. Instead of looking at machines and IPs when workloads boot up, the administrator will see that services will be able to control where they run.

    This will also enable you to intuitively create identity-based micro-segmentation. This is an advantage since micro-segmentation was always a complicated task to achieve, requiring administrators to map an application to the network while keeping track of what is running in the environment.

    With identities and a service mesh layer, it is only necessary to focus on your business logic. The fact that identities were generated during the CI/CD pipeline, provides the ability to control the application without the need for service discovery. Identities are represented by their business-context names, originating in the CI/CD pipeline, so the operator can easily group them together and assign policies at different layers of granularity.

    K8s is a great technology that enables the harvesting of containerized environments. Adopting it can accelerate your organization’s digital transformation dramatically, but it can also require you to adopt new methods of application security. Contracting with a k8s-focused security organization will allow the business to accelerate its migration to cloud-native applications on-prem and in the cloud, in a most automated fashion.

    By providing the needed security and operational capabilities, k8s clusters admins are afforded an enterprise-level micro-segmentation solution with policy orchestration, single pane of glass to your clusters in a multi/hybrid cloud deployment and the ability to connect between containerized clusters and legacy applications, as well as other resources that are external to the cluster.

    — Ran Ilany

  • CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI has achieved a SOC 2 compliance rating for the DevOps platform it makes available via a software-as-a-service (SaaS) model.

    Tad Whitaker, security manager at CircleCI, said CircleCI is the first provider of a SaaS platform for DevOps that has invested the hundreds of thousands of dollars required to achieve SOC 2 compliance.

    SOC 2 compliance requires organizations to pass an annual audit based on the Trust Services principles and criteria defined by the American Institute of Certified Public Accountants (AICPA). That criteria evaluate IT environments on everything from the cybersecurity controls they have in place to the integrity of the data management processes employed. A SOC 2-level certification means DevOps teams can have confidence in the fact that their data is being kept completely confidential, said Whitaker.

    With interest in best DevSecOps processes on the rise, Whitaker noted more organizations are starting to ask questions about how data is managed and secured on the cloud services they rely on to build and deploy applications. Cybersecurity professionals who are now participating in those processes are starting to ask challenging questions. To address those concerns, Whitaker said CircleCI created a team within the company to first attain SOC 2 compliance and, now, maintain it.

    That may lead to additional processes and controls being put in place, but DevOps teams can be confident that everything possible is being done to secure their data from prying eyes, including employees of CircleCI.

    A lot of the data being employed to build new applications is among the most sensitive an organization is likely to possess. As organizations embrace DevOps practices to drive digital business transformation initiatives, there’s a much greater need to ensure the DevOps environment is secure end to end. However, most of the DevOps platforms delivered as a service today are not able to validate the level of security they claim to have put in place, said Whitaker.

    It’s unclear how many organizations are going to insist of SOC 2-level certifications before agreeing to develop applications on a specific DevOps platform. However, SOC 2-level certifications are routinely required for cloud service providers so it’s only a matter of time before the same audit requirements are applied to other cloud services. The challenge will come when DevOps teams have to adjust their existing DevOps processes to accommodate the security processes that SOC 2-compliant cloud service providers are required to make.

    In the meantime, the days when DevOps teams could employ cloud services to bypass cybersecurity policies are coming to an end. Cybersecurity teams are finally catching up in terms of figuring out how to enforce cybersecurity policies beyond an on-premises IT environment. Not every DevOps team may appreciate the impact those policies may have on productivity. However, if the alternative is to have sensitive data that DevOps teams are now being held accountable for exposed on the web because of careless processes than the time to come to terms with cybersecurity has finally come.

    — Mike Vizard

  • Data Monoliths Go Cloud-Native with Kubernetes

    Data Monoliths Go Cloud-Native with Kubernetes

    Breaking monolithic applications into independently scalable services is the core of the cloud-native application model. By making cloud-native apps easy to deploy and manage, Kubernetes has contributed to a big change in IT practices.

    Initial cloud-native conquests started with stateless services and quickly grew to encompass applications that manage data. Database management systems have long relied on centralized servers, but cloud-native architectures are now reaching even the largest monoliths. Among the most interesting cloud-native converts are analytic databases, which hold data arranged in storage formats optimized for extremely fast analytic queries over billions ,or even trillions, of rows.

    The transformation of databases to cloud-native models has profound implications for data-driven applications. Intersecting trends in analytic database architecture and Kubernetes promise substantial benefits to the users of such applications as well as companies that operate them.

    The Rising Importance of Analytics

    Over the last decade the quantity of data that businesses generate has decoupled from the size of the business itself. Ad networks, website analytics and service observability applications often ingest 1 million events per second (or far more) and may have tables running into trillions of records. Businesses need to analyze this information rapidly–for example, to diagnose faults in cloud applications or to retrain models for displaying online ads. Flexible, real-time analytics have gone from nice-to-have to business critical.

    Meanwhile, new analytic engines have emerged that eliminate dependencies on specialized hardware and complex networking required by legacy data warehouses. Druid, ClickHouse or Elasticsearch run on commodity hardware and depend on basic compute, network and storage. Everything else, such as high availability (HA), is built into the application. Newer analytic databases offer built-in horizontal scaling using fleets of server processes. The server processes themselves typically run well in containers.

    With these changes, analytic databases are increasingly cloud-friendly if not cloud-native. It is a short hop to deployment on Kubernetes.

    Kubernetes Operators for Databases

    At the same time, as analytic databases have shifted their operational model, Kubernetes itself has become more welcoming for databases.

    One particularly important innovation for the database is custom resource definitions, or CRDs, which extend the Kubernetes API to define new types of manageable resources. Using CRDs makes it possible to have a single definition that shows the desired state of a complex application such as a data warehouse.

    Another addition is Kubernetes operators, which manage custom resource definitions. Operators track custom resource definitions and take actions when they change. They can also track other information that might be relevant to managing the custom resource, such as changes to pods, storage or even related cloud-native applications. It’s like having a human operator who is constantly watching the application, except the rules are programmed into software that runs inside Kubernetes itself.

    The operator pattern is a perfect match for analytic databases, which are complex distributed applications and may require definition of dozens or even hundreds of individual Kubernetes resources in a running system. Operators encapsulate these details as well as important procedures such as upgrade, scale-out and other operations that require careful manipulation of resources to prevent outages.

    It’s not surprising operators are popular with database developers. The OperatorHub.io registry for database operators alone has 19 entries covering databases of every kind, including analytic databases such as ClickHouse and Elastic. Many more exist outside the registry.

    A Cloud-Native Way to Consume Analytic Databases

    New data warehouse architectures and Kubernetes operators means users can now use analytic databases very differently from legacy data warehouses. Our work on ClickHouse, including development of the ClickHouse Kubernetes Operator, prompts two observations.

    First, operators make spinning up analytic databases simple and fast for all users. Amazon Redshift kicked open the door to data warehouse-as-a-service in the public cloud. Kubernetes operators enable similar capabilities not just in public clouds but any Kubernetes cluster. Individual developers can cycle through dozens of configurations in a single day while testing new analytic applications. Thanks to quick pod spin-up new analytic databases can be running in minutes or even less.

    More profoundly, users can use Kubernetes to move to an on-demand model for analytics. Rather than forcing all applications to compete for resources on a single shared cluster, each application can have an analytic database tuned to its specific requirements. Analytic databases can integrate tightly with applications in the same locations where those applications already run. Businesses can scale databases flexibly to deliver quality analytics at exactly the time they are needed and at reasonable cost. This is the heart of the cloud-native programming model.

    Modern database architectures combined with Kubernetes features, such as the operator pattern, are creating a new path to manage enormous volumes of data. For readers who are hesitant about managing data on Kubernetes, it’s time for another look.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Robert Hodges

  • Cloud Native Tracing and Observability: Why You Care

    Cloud Native Tracing and Observability: Why You Care

    Is observability the new monitoring? Or is observability, and tracing, fundamentally different? Like any IT industry trend, it can be difficult to discern as many jump on the trend bandwagon, appropriately or not. The Splunk .conf 2019 event presented Splunk with the opportunity to bring clarity to the terms and the reasoning behind the acquisitions of SignalFx and Omnition.

    Monitoring is mostly about taking events, telemetry data and established data points and thresholds into monitoring, alerting and problem management processes and tools. Its tried and true, and has progressed with the evolution of typical monolith, distributed apps and systems. Enter cloud-native applications, composed containers, microservices and service meshes. With great flexibility comes complexity, and cloud native isn’t immune to such an adage.

    What would have been a monolithic application is now shattered into hundreds or even thousands of smaller pieces of application and app technology software. The complexity of externally monitoring cloud native quickly surpasses the capabilities of most monitoring approaches.

    Observability, as recently acquired SignalFx CTO Arijit Mukherji shared this week, is built upon three pillars: metrics, tracing and logs. Metrics show when you have a problem, tracing points you to the problem and logs help find the root cause—a reasonable way to define and segment observability. It also, not surprisingly, fits well with the logic of Splunk plus SignalFx plus Omnition.

    To move beyond monitoring requires instrumentation, built into the software and APIs as part of the software creation process, a DevOps process. SignalFx in part brought Splunk auto-instrumentation, which during run-time, identifies frameworks and libraries in use within applications and can capture tracing instrumentation. Omnition brings even deeper tracing chops to perform tracing across large service meshes of microservices. Add Splunk’s capability to correlate data across the business, applications and operations data and you complete the picture with the ultimate goal of making observability easy for developers.

    The above might explain why developers, ops and DevOps care about observability and tracing, but should the business care? SignalFx CEO Karthik Rau connected the dots nicely during a conversation this week. Digital transformation strategies require speed and agility, but also demand more risk-taking. Confidence in risk-taking comes when accompanied by the ability to respond rapidly to changes and failures. A software deployed 10 minutes ago may need to be backed out or corrected rapidly when the users’ experience goes negative. That requires a rapid determination of what the problems is, and the ability to take immediate corrective action, including automated action.

    Cloud native and DevOps not only enable disruptive, digital transformation strategies but must be accompanied by rapid and automated responses when negative business and customer impacting conditions occur. Customers don’t care when CPUs are taxed, but they do care when a mobile app’s responses fail or are slow. The move to cloud native is served well when backed up by such capabilities to respond in near real-time when problems occur.

    — Mitchell Ashley

  • CNCF Advances CloudEvents Specification

    CNCF Advances CloudEvents Specification

    In a move that portends well for future cloud interoperability initiatives, the Cloud Native Computing Foundation (CNCF) today announced that the open source CloudEvents specification for describing event data had achieved a version 1.0 milestone.

    Doug Davis, senior technical staff member of IBM and co-chair of CNCF’s Serverless WG and the CloudEvents project, said CloudEvents will make it possible to not only define common attributes of an event to facilitate interoperability, but also make it easier to share those attributes between, for example, a repository such as GitHub and an application or tool that needs to consume those events.

    With that foundation in place, it also should become easier to build tools spanning serverless and event-driven architectures, he added.

    Work on the CloudEvents specification began in May 2018 as a sandbox project. With the release of CloudEvents 1.0, the CNCF Technical Oversight Committee (TOC) is now designating CloudEvents as an incubation project. Active contributors to the CloudEvents project include Amazon Web Services (AWS), Google, Microsoft, IBM, SAP, Red Hat and VMware. In fact, CloudEvents has already been implanted within the Eventing framework of Knative, an open source middleware project led by Google to integrate Kubernetes with various serverless computing frameworks. Other platforms that support CloudEvents include Microsoft Azure Event Grid, Red Hat EventFlow, Eclipse Vert.x and Debezium, SAP Kyma and the Event Gateway from Serverless.com.

    Davis said given the level of support for CloudEvents project, there is reason to be optimistic for future cloud interoperability initiatives. Cloud interoperability has been hampered by a dizzying array of application programming interfaces that often are proprietary. CloudEvents represents one of the few interoperability projects that has drawn support from all the major cloud service providers. Part of the success CloudEvents has enjoyed in that regard can be attributed to the limited scope of the initiative, he noted.

    It may be a while before organizations don’t have to worry about being locked into a cloud. However, as a general rule of thumb the more they focus on de facto specifications and application programming interfaces (APIs) exposed by platforms such as Kubernetes, the easier it will be to move applications from one platform to another. In many cases, DevOps teams today routinely struggle with moving applications that might have been developed on a public cloud onto an on-premises production environment. Longer term, it’s also expected IT leaders will want to be able to negotiate lower rates from cloud services providers by threatening to move workloads between cloud service providers.

    In the meantime, as event-driven architectures such as serverless computing frameworks continue to become more popular, IT leaders can take some comfort in the fact that interoperability across these architectures is advancing. Of course, it’s too early to say when the CloudEvents specification will become a fully graduated CNCF project, but it is already apparent many cloud service providers are not waiting on that official recognition before implementing it. The challenge and opportunity for DevOps teams now are to figure out how best to employ this capability to create new applications that previously would have been too difficult even to attempt.

    — Mike Vizard

  • From Pets to X-as-Code: Enabling Control and Predictability for ITOps at Scale

    From Pets to X-as-Code: Enabling Control and Predictability for ITOps at Scale

    Amy Wheelus, vice president of network cloud at AT&T, recently spoke about declarative predictability at the Open Networking Summit in Antwerp. AT&T is the world’s largest telecommunications company providing mission critical communication services where people’s jobs–and lives–can be on the line. As they move away from labor-intensive IT operations toward cloud-native automation, there is a need to trust the declared IT infrastructure state can be predictably controlled and reproduced. This requirement to build predictability, reproducibility and trust into IT systems is not new but has grown in both scale and complexity as IT departments went from a few servers blinking in the basement to the core around which every business rotates. 

    With every customer interaction and business function becoming more digital, companies must be able to rely upon their IT departments if they hope to continue to keep pace in today’s rapidly changing world. This article traces the evolution of IT operations from Pets towards X-as-code with each improvement bringing companies closer to declarative predictability. These best practices enable enterprises to reliably deliver core business value through their IT department and keep pace in the cloud native era.

    Yesterday: Pets Versus Cattle and Infrastructure as Code

    Back when the IT department was just servers in the back room, it was all hands on deck when anything went wrong because work ground to a halt. The CEO couldn’t get their emails and the sales department couldn’t book new orders. From these early days, it was learned that in order to trust IT with critical business services, high availability and reliability needed to be built into the system. This lead to the creation of the Pets vs. Cattle analogy where each infrastructure component is interchangeable and can quickly be replaced when anything goes wrong. This allows companies to quickly recover from or even avoid outages.  

    While treating servers as cattle solves some problems, as any rancher can tell you, handling a whole heard brings its own set of challenges. As the size of managed infrastructure grows, it can be difficult to keep track of where, when and how it is actually deployed. In addition, changes to production systems to keep them healthy can lead to configuration drift creating unique snowflake servers which are pets rather than cattle. It becomes a difficult task to predict how a system will react or rely upon it in critical situations when its actual state is unknown.

    To help eliminate this problem and control how infrastructure is configured and deployed, ITOps teams moved to infrastructure-as-code. In this way of working, applications and servers are never modified once deployed. If something needs to be changed, a new version is created and the old one is decommissioned. Each deployment can be versioned to create an overview of what is in production and how it is deployed.

    Managing cattle rather than pets and using infrastructure-as-code has helped companies move from ticket-based operations with long lived machines to more scalable and dynamic infrastructure. These practices build reusability, scalability, automation and versioning into IT systems to create a simpler, more predictable deployment and management process. By being able to declare the state of its infrastructure, companies are able to predict and trust the outcome.

    Today: Cloud-Native Infrastructure

    Looking at the definition of cloud native from the Cloud Native Computing Foundation, it quickly becomes clear why many companies are turning toward these best practices. They help companies build and run resilient and manageable infrastructure that–combined with robust automation–creates dynamic, yet predictable systems. Declarative APIs and immutable infrastructure will be used as two examples to understand how cloud native builds upon and expands the techniques covered above.

    Declarative APIs make infrastructure as code and automation possible. For example, with Kubernetes, operations teams are able to declare the desired state of the system and automate the reconciliation with the actual state until they match. It originally began with just container orchestration but has since expanded to cover many other types of cloud resources including the physical infrastructure itself through Custom Resources and Cluster API respectively. Declarative APIs make infrastructure management simpler and more reproducible by automating operations and eliminating errors in production. Declarative APIs can be leveraged to create immutable infrastructure.

    Immutable infrastructure goes beyond just servers as cattle and only treating the infrastructure as code. Immutable infrastructure covers every higher layer of the stack until each one is codified and managed like cattle. Only exact copies are deployed and they can be completely replaced at any time. If anything needs to be changed, a new deployment is made and the old ones are decommissioned. Immutable infrastructure works for the whole stack to eliminate variations leading to fewer deployment failures, consistency across environments, easy horizontal scaling and a simple rollback and recovery process.

    As these two examples show, cloud native enables companies to reliably scale out dynamic IT services without having to simultaneously scale out their operations team. Building declarative predictability into systems engenders trust in automatic processes, even when critical services are running on them.

    Tomorrow: X-as-Code

    While cloud-native best practices provide many benefits, applications and infrastructure are just the beginning of the story for enterprise IT teams. In today’s world, they are presented with the Herculean tasks to manage a dynamic and sprawling environment while still keeping in compliance with internal policy along with national and international laws. This challenge moves far beyond mere servers and treating them like cattle to compliance and governance across multiple clouds and hundreds or thousands of developers. With these challenges in mind, the question still remains on how to best deliver on these demands at the enterprise scale.

    Looking across architecture, configuration, blueprinting, policy and governance, if each of these is simply viewed as another layer of the stack above the application, their operations can be radically simplified. By applying the principles of immutable infrastructure and cattle to this further layer of the stack, each of these can be defined and managed using an X-as-code model. These types of management models can already be seen taking root across the cloud-native ecosystem.

    Kubernetes creates blueprints-as-code through the use of Admission Controllers while policy-as-code can be defined in Pod Security Policies and Network Policies. The CNCF even has a policy engine, OPA, as a sandbox project that gives operators fine-grained yet flexible policy control across their entire stack. By using code to decouple policy and other layers from the actual implementation, the resulting stack is easier to understand, flexible enough to handle future requirements and less expensive to maintain.

    At Loodse, our customers were struggling to manage configuration, services and policy across their clusters. Leveraging the Kubernetes controller paradigm in Kubermatic, we are able to automate the deployment and lifecycle of each of these add-ons. This gives users the ability to declare, enforce and automate the required state of not only the infrastructure but the configuration and policy, too. Kubernetes controllers bring predictability and control to dynamic and scalable cloud-native IT even as it begins to handle more and more mission critical services.

    Cloud Native in Production: Declarative Predictability

    With IT becoming the core of every business, bringing cloud-native best practices into production enables operators to predictably declare, run and manage their infrastructure at the enterprise scale. Being able to trust in these automated operations frees up resources and opens up many new possibilities. Developers can be given guardrails and become empowered to do their job rather than waiting in a ticket queue. Operators can easily create highly available self-healing infrastructure that meets governance standards allowing them to focus on delivering a platform with differentiated business value.

    At each step of the development of modern IT practices, from cattle to X-as-code, operational processes have become more streamlined allowing both developers and operators to drive more value to the bottom line. The future of IT infrastructure and operations will be a trusted platform that automates undifferentiated heavy lifting, allowing the whole business to focus on customer value.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Bill Mulligan

  • Talend Aligns With Microsoft on DevOps

    Talend Aligns With Microsoft on DevOps

    Talend has made its integration platform natively available on the Microsoft Azure cloud to provide DevOps teams employing Azure DevOps with an easier approach to creating pipelines and integrating data.

    Vincent Lam, head of cloud product marketing for Talend, said the company is now making available 900 connectors and components to DevOps teams that use the continuous integration/continuous deployment (CI/CD) platform Microsoft offers as a service.

    TalendBy providing deep hooks into the Azure platform, Lam says Talend is looking to make it easier for teams to build applications by relying on an integration platform-as-a-service (iPaaS) environment to access data stored in Microsoft cloud services such as Azure SQL Data Warehouse, Azure Databricks, Azure Data Lake Store and Azure HDInsight.

    From a DevOps perspective, the Azure DevOps Orchestration engine has now been integrated with Talend’s zero-install continuous integration capability, which it created as part of an effort to integrate its integration service with CI/CD platforms such as Jenkins. That effort made it possible to leverage CI orchestration tools to automatically build unit tests and package Talend jobs in an artifact repository. That capability has now been extended to Azure DevOps.

    Not every organization that uses Azure will employ Azure DevOps because they may have already standardized on another CI/CD platform, which they prefer to deploy and manage. However, because Azure lowers the barrier to entry for employing DevOps to build applications, Talend is now seeing a lot of demand for an iPaaS environment on Azure, Lam said.

    Regardless of platform, as organizations start to build cloud-native applications based on microservices, many of them underestimate the integration challenges they will face. Each microservice has its own application programming interface that needs to be built and supported, which in turn is driving more convergence of DevOps platforms and iPaaS environments to help manage the APIs on which those microservices depend. As a result, IT organizations today need to apply more forethought to their overall API strategy, said Lam.

    Talend is not the only provider of an integration platform to appreciate the role that DevOps processes and the rise of microservices are having on driving increased consumption of integration services. But it’s not clear whether access to integration services will become more democratized across IT organizations. Rather than continuing to rely on “centers of excellence” to centrally manage integration projects, many IT organizations have come to realize DevOps teams need to be able to access integration capabilities on demand. To facilitate that process, vendors such as Talend are making a concerted effort to couple integration platforms tightly with various DevOps platforms.

    It remains to be seen to what degree integration platforms will remain standalone platforms versus becoming a capability to be invoked within the context of a CI/CD pipeline. Given the volume of monolithic applications that still depend on centrally managed integration platforms, it may be a while before the integration platform becomes subsumed in DevOps platforms. In the meantime, however, the line between DevOps and integration platforms will surely get more blurry.

    — Mike Vizard

  • Building Hybrid and Multi-Cloud Architectures for Analytics and AI

    Building Hybrid and Multi-Cloud Architectures for Analytics and AI

    We are in the early stage of the data revolution. Today’s conventional wisdom states that hybrid latency prevents you from running analytic and machine learning workloads in the cloud with the data on-prem. As a result, most companies either do not burst their workloads into the cloud or have to copy their data into a cloud environment and maintain that duplicate data—and even this can take days or weeks.

    Counter to conventional wisdom, you can create a high performance hybrid/multi-cloud data platform for analytics and machine learning by using data orchestration technology. Container orchestration technology (e.g. Kubernetes) enables containers to run in any environment agnostic to the hardware that is running the application, similarly data orchestration technology enables active working sets and data to be orchestrated on demand. This enables enterprises to create a compute agnostic, storage agnostic and cloud agnostic stack to serve all their data driven workloads, including analytics (e.g. Apache Spark, Presto, Apache Hive) and AI (e.g. Tensorflow, PyTorch).

    An enterprise hybrid cloud analytics strategy should burst compute that spans on-prem and cloud data stores. By bringing the hot data to the analytics and machine learning applications, the performance is the same as having the data co-located in the cloud. Also, the on-prem data stores will have offloaded the computation and minimized the additional I/O overhead.

    Specifically, a data orchestration system should:

    • Abstract data access across storage systems. Today, data is siloed in various storage systems and deployments. For example, lots of on-premise data is stored in systems such as Apache HDFS, Ceph, EMC Isilon and IBM Cleversafe, and data in the cloud is stored in systems such as AWS S3, GCP Store, Alibaba OSS, etc. Historically, there have been many attempts to unify all data into a single storage deployment with limited success. As a result, we’ve seen more of a trend around embracing these data silos by abstracting the data in various storage systems/deployments. To do this, the data orchestration system needs to abstract and virtualize across various storage deployments/deployments by server side API translation, which enables users to run existing applications without modifying any code. The system also needs to provide a single global namespace to enable apps and users to access all the data in their environments without the need to understand which storage the data is stored in.
    • Bring data locality in a separated compute and storage environment. While cloud vendors and leading companies in data-heavy industries have adopted a decoupled compute and storage architecture, it can still be very challenging to implement this type of architecture, especially when it comes to bursting on-premises data into the public cloud. A data orchestration system resolves this challenge by providing caching functionality that enables the system to automatically orchestrate the hot data to be closer to compute while at the same time keeping cold data in a cheap storage. Because each workload may have a different usage pattern, the system must have a policy that enables customized policies best suited for those specific workloads. Moving forward, it is also very critical to have policies across various clouds to enable a multi-cloud environment.
    • Provide security for data in motion and at rest with secure access methods. A data orchestration system plays a critical role in the success of an organization’s data strategy. While open source software is important and can help in avoiding potential vendor lock-in, it is also critical to provide necessary security features in this environment given the system touches a lot of data in the organization.

    Besides empowering data driven application developers, a data orchestration system also brings value to data and infrastructure engineers. It de-risks vendor lock-in by providing organizations with flexibility at the infrastructure level. Transitioning to different storage systems (including cloud storage), adopting another application framework, or even having a hybrid or multi-cloud environment are all possible without the need for many different technologies or incurring large development costs.

    — Haoyuan Li