devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Opsani Applies AI to Rein in Cloud Costs

    Opsani Applies AI to Rein in Cloud Costs

    Opsani has added support for cloud computing environments to its namesake software-as-a-service (SaaS) platform that leverages machine learning algorithms and other forms of artificial intelligence (AI) to optimize the IT environment.

    Company CEO Ross Schibler said Opsani AI not only proactively tunes resources such as CPU and memory, but it also can optimize middleware configuration variables such as Java virtual machine (JVM) type and pool sizes; kernel parameters such as page sizes and jumbo packet sizes; and application parameters such as thread pools, cache timeouts and write delays.

    Given the size and dynamic nature of most cloud computing environments, Schibler said it’s not possible for IT administrators to manually optimize cloud computing environments to match the specific needs of each class of application workload being deployed. The Opsani platform makes it possible to leverage AI to optimize settings for the lowest cost or best performance every second, he said.

    Opsani claims existing customers are seeing more than 200% increases in performance per dollar while saving up to 80% on their cloud spend.

    In addition, Opsani has made available plugins for a variety of DevOps tools including GitHub, Terraform, Jenkins, Spinnaker, Wavefront, DataDog, SignalFX, Prometheus, Splunk and New Relic, on all the major cloud computing platforms.

    Schibler said Opsani can be applied to existing monolithic applications as well as emerging microservices-based applications based on containers running on Kubernetes clusters. The goal is to make it possible for IT teams to rein in cloud costs at a time when most cloud resources are being employed inefficiently, he said.

    Individual developers are deploying applications on virtual machines in the cloud with little to no appreciation for total cost, noted Schibler. Before most IT organizations realize it, the cost of running applications on a public cloud has far exceeded budget allocations. IT organizations not only need tools to rein in those costs, but Schibler noted Opsani also makes it possible to model those costs before an application is deployed or upgraded.

    The adoption of public clouds and DevOps often go hand in hand. The challenge organizations are encountering more often is that as the number of applications running in a public cloud computing environment increases, they often wind up overprovisioning resources. Over time, the need to optimize the consumption of cloud resources becomes a more pressing financial concern. However, most IT organizations don’t have the resources or expertise needed to manually tune each instance of cloud workload. At the same time, the typical IT organization doesn’t have the ability to build its own AI engine. Opsani is making the case for a SaaS platform that provides that capability without requiring an IT organization to build its own AI models from scratch.

    Naturally, many IT professionals are dubious of AI because there may not be enough transparency into the AI models being employed. However, because Opsani is a SaaS platform, the risk of experimenting with AI to optimize cloud workloads is relatively slight. Of course, there’s no absolute requirement to employ AI at all. However, as financial pressure on IT organizations continues to mount, there doesn’t seem to be much of an alternative either.

    — Mike Vizard

  • The Disservice of Cloud Consolidation

    The Disservice of Cloud Consolidation

    There’s no secret that over the past five years especially, the major (“tier 1”) cloud infrastructure players—Amazon, Microsoft and Google—have been snatching up smaller specialty providers, particularly cloud migration and security services.

    While this acquisition strategy immediately aims to strengthen and expand the provider’s direct and tangential cloud infrastructure offerings, the long-term goal is customer attraction and retention.

    In consolidating cloud infrastructure and related services, cloud vendors are targeting a basic human desire that often bleeds over into business decisions: convenience.

    • “Finding a cloud provider seems hard.”
    • “Switching to the cloud seems hard.”
    • “Managing more than one cloud seems hard.”
    • “Keeping up with more than one vendor seems hard.”

    The play is transparent; the marketing is already in your psyche. People don’t like doing more than they have to, whenever possible. So, why not apply that tick to the cloud infrastructure experience? Why not use a provider where everything is already in one place?

    Truthfully, the move toward cloud consolidation is a step in the opposite direction from where we should be going. The future lies in a multi-cloud approach, not a consolidated one.

    Multi-cloud approaches offer both businesses and their customers several advantages over consolidated infrastructure.

    • When a business’ cloud infrastructure exists solely with one provider, every cloud-related business activity—and every customer interaction with those activities—is beholden to the provider. A provider outage is a business-wide outage, and a business-wide outage is unacceptable.
    • Multi-cloud approaches allow businesses to take advantage of best-of-breed cloud infrastructure. A business can implement databases, containers and other virtual infrastructure in a more highly optimized way.
    • Data held in disparate systems can be better partitioned and more secure than data stored with a single provider. Also, these disparate systems can bolster adherence to existing (and likely coming) data privacy laws and compliance regulations both nationally and internationally.
    • Utilizing cloud infrastructure housed physically closer to a business or its key users can drastically influence business activities in industries where parts of seconds count (e.g., finance).

    Aside from the standard reasoning, I’d argue that there’s additional economic health in taking a multi-cloud approach. Competition naturally drives innovation, stabilizes costs and encourages improvement. Where one provider may falter, three others might specialize. If the majority of businesses consolidate their cloud resources with a single provider, though, the likelihood increases of services gradually worsening with no alternatives toward which to turn.

    Multi-cloud takes planning and coordination to properly implement, and careful monitoring to maintain. An additional tool or two, such as a cloud management platform or cloud integration solution (which, truthfully, many businesses are likely already utilizing), may be needed.

    But, the benefits far exceed the challenges. After all—to call upon Ken Jenkins’ iconic chief of medicine, Bob Kelso—nothing worth having comes easy.

    — Zack Busch

  • Service Meshes: Improving Security, Delivery and Availability

    Service Meshes: Improving Security, Delivery and Availability

    Containerized microservices are taking over the software world. These services provide developers a way to quickly create and deploy cloud-native applications. However, containers aren’t perfect. Orchestrating and managing container deployments can be a serious challenge. 

    To help ease this challenge, service meshes were developed. In this article, you’ll learn about service meshes components and architecture options. You’ll also learn how services meshes can improve your container deployments.

    What Is a Service Mesh?

    A service mesh is a dedicated communication layer that sits on top of your request/response layer. It works similarly to a Container Networking Interface (CNI), which controls the connection of your services to your network. A service mesh sits on top of your CNI, adding additional functionality, such as service discovery or security. A service mesh is not a replacement for a CNI or a service orchestration platform.

    Services meshes are designed for use with containerized microservices. You can use this technology with any container or container orchestration tools. However, the most active projects seem to favor developing service meshes for Kubernetes.

    Service Mesh Architectures

    When deploying a service mesh, there are three architectures you can choose from.

    Library 

    The library architecture employs a library that is imported in an application’s code and runs from inside the application. Using a library eliminates the need to call out to a remote service, making it more secure.

    Libraries make it easier to allocate resources since all work is contained in the microservice running the library. A library architecture works well for in-house applications that are written in one language. Third-party applications are difficult or impossible to add the library to.

    Node Agent 

    A node agent architecture uses a node agent or daemon that serves all containers on a particular node. A node agent architecture is language-agnostic since it doesn’t run from inside your microservice. It can be used with in-house and third-party applications. However, node agents must be coordinated with infrastructure processes, making this architecture more complex to deploy.

    Node agents require less memory than sidecars since information can be shared across a node. This architecture employs work resource sharing, with dynamically shared resources, making it easier to scale. The downside of sharing, however, is that it can be abused, with one service hogging all available memory.

    Sidecar Proxy 

    A sidecar proxy architecture uses sidecars that run alongside your containers. The sidecar handles all traffic into and out of the container it is attached to. Sidecars do not require coordination with your infrastructure since one proxy is assigned to each container. This lack of coordination makes sidecars easier to set up than node agents.

    Sidecars only serve one pod and are not influenced by other pods. This isolation makes this architecture better for zero-trust deployments as each container is accountable for its own actions. Sidecars can be added to containers at any time, enabling you to easily scale processes.

    Use Cases For Service Meshes

    Service meshes are an emerging technology, with new use cases being actively developed. The three use cases introduced here are just the ones that are currently most common.

    Improving Security

    Containers are isolated environments and generally considered to be more secure than traditional applications. However, containers still contain vulnerabilities, such as possible abuse of root access. 

    Service meshes can help address security concerns by providing:

    • Zero-trust security—any communication, either from inside or outside requires verification. Verification prevents compromised containers from interfering with other microservices or your broader system. It restricts a container’s actions and communications to that container alone.
    • Communication tracing—enables you to collect communications information and isolate errors or issues. If a container is communicating in an unexpected way or against protocol, you can identify it. Once identified, you can easily replace the container with an uncorrupted image or remedy the issue. Tracing enables you to pinpoint possible attacks, including where attackers came from and what they’re trying to accomplish.

    Improving Delivery

    Containers already improve on application and service delivery by making it easier to release and patch services. Service meshes expand upon these capabilities by improving application and performance monitoring functions. 

    Service meshes can also help improve service delivery by enabling:

    • A/B testing—provides advanced routing, enabling you to divide traffic between A and B versions. This routing makes it simpler to set up A/B testing. Additionally, tracing features enable you to gather and analyze user traffic and interactions.
    • Rapid versioning—new versions can be released with zero downtime and reduced risk. Containers can be started and verified healthy before traffic is gradually shifted between versions. If issues arise, changes can be rolled back without system-wide consequences. Easier corrections enable you to relax delivery requirements with minimal risk.

    Improving Availability

    Containers can provide improved availability, depending on your hosting configuration and resources. Service meshes can expand upon these abilities by improving load balancing, traffic management and health monitoring functionalities.

    Service meshes can also help improve availability by enabling:

    • Resilience testing—enables you to test how services respond with fault injections. Service meshes enable you to test your services’ fault tolerance. Increased understanding of how faults affect resilience helps you identify and correct vulnerabilities. Greater service resilience leads to greater availability.
    • Deployment and request shadowing—enables you to simulate anticipated traffic flow and see how services respond. Shadowing enables you to test the traffic and workload capacities of your services. With this information, you can determine whether you need to scale resources and connections. Proper scaling ensures that your traffic needs are met and prevents traffic bottlenecking and decreased availability.

    Conclusion

    As microservices become standard, teams are placing an increased focus on improving container performance and security. The development of service meshes is a result of this increased focus.

    Hopefully, this article helped you understand what service meshes are and how this technology can help improve your container deployments. If you’re interested in seeing how a service mesh might help you, check out this tutorial explaining how to build a service mesh.

    — Gilad David Maayan

  • APM for All: Simplifying the Complexity of Cloud

    APM for All: Simplifying the Complexity of Cloud

    As companies adopt hybrid and even multi-cloud strategies, their IT departments are beginning to use dynamic technologies to build new application features on top of existing back-end business systems. Most organizations now have a blended, multi-cloud architecture where public clouds are integrated with the existing on-premises, private or hybrid cloud infrastructure and applications.

    This means, for all the agility, flexibility and scalability the cloud affords us daily, the cloud is also a source of increased complexity for technology professionals required to assure the availability and performance of the application environment. This, in turn, is expected to have a substantial impact on overall management. Gartner predicts that by 2020, “75% of enterprises will experience visible business disruptions due to infrastructure and operations (I&O) skills gaps.”

    It’s vital, then, to first understand the underlying technologies supporting application availability and performance throughout your entire IT environment. Next, you must understand how your technologies are dynamically interacting with each other in both development and production. And you need to know this not just at the various levels of the application stack itself—across all infrastructure as well as services, function calls and code—but for various types of applications themselves: monolithic, service-oriented architectures (SOA) and microservices-based.

    That’s why, whether on-prem, hybrid or cloud-native—and whether you’re running AWS, Azure or Google Cloud (IaaS or PaaS)—you need comprehensive visibility into your complete infrastructure and application stack. Application performance management (APM) gives you this visibility into your IT environment by simplifying, and more importantly, normalizing, app stack management. 

    The Case For APM

    APM has significant business value. In today’s environments, an IT team typically no longer has only one application per virtual machine—but rather dozens of virtual machines per physical host (whether on-premises, private or public cloud), with hundreds or thousands of containerized microservices per virtual machine. Additionally, these business environments with hundreds (or many thousands) of containers are continually being reconfigured and brought in and out of production underneath customer-facing applications. If something goes wrong, the digital operations can collapse. And they all need to play nice together since the underlying resources are shared.

    At the same time, the game has changed. The red, yellow and green glow of infrastructure dashboards now has less bearing on whether you’re really delivering high-quality user experiences. Instead, success metrics are now based on evolving real-world, end-user experiences. You are customer-facing, because clients interact with you through your applications and websites. If your site is slow, you lose money and it negatively impacts the business brand.

    To fix the problem, you need specifics. For example, is the transactional performance slow because you don’t have enough compute? Or is it slow because the application code is bad? These factors are interrelated. In our dynamic, shared-and-virtualized everything environments, it’s challenging to understand where the true causes of your problems are.

    When Amazon went down for an hour during Prime Day last year, experts estimated the company lost 100 million dollars in sales. Imagine the impact of a potential outage during the holiday season. Of course, those are Amazon-sized numbers. But scale down those Godzilla figures to your size, and it still hurts—either through lost revenue or damaged brand reputation.

    With APM, you can see all the metrics and find out how the application’s performing over time. You can see it degrade, giving you time to figure out why it’s slowing—before it stopped getting you your raw materials on time. You can understand down to the line of code, or database query, exactly what, where and why it’s slow.

    But what are we talking about when we talk about APM? Gartner has pointed out the historical confusion on terms. There’s also a matter of differing capabilities among APM tools. Some are geared toward monolithic applications; others for Java and the web (and other applications) and still more are tuned for microservices. Beyond that, there are full-stack APM solutions that can measure it all.  

    Normalizing IT Management With APM

    APM strategies and toolsets aren’t all the same. By my count, there are three iterations of APM implementations. First, there’s APM dating from when all tech was monolithic, of which the best example is the old CA Wily Introscope. Then came a second generation, which covered areas such as SOA, Java and the web—a good example here would be AppDynamics and the old Dynatrace. After that comes a version of APM tuned specifically for microservices and containerized application environments, such as the new Dynatrace and Instana.

    In some cases, the actual APM technologies themselves haven’t kept up to date with the underlying infrastructure changes. That’s especially true for microservices. There are some legacy APM solutions that don’t support microservices in containerized application environments. On the flip side, some new companies in the APM space only operate in the microservices space. They are container-based, and don’t support old monolithic code. They also don’t support n–tier/SOA application environments.

    Most customers, however, have mixed environments. Almost no one is operating with 100% microservices in containers operationally managed by Kubernetes.

    By my reckoning, modern APM systems should monitor it all, because everything is mixed and likely to stay that way, if history is any indication. Companies still rely upon massive databases of proprietary information—databases of business records. They’re just building all-new applications in front of them.

    If you posit that it’s now more important than ever to ensure availability and performance as experienced by the user, then you need APM across all those three categories of applications and their environments, including public cloud providers such as AWS and Azure. You need full-stack APM.

    Getting Started

    Before you do anything else, first remember your due diligence. Ask around and seek out first-hand knowledge about the APM solution vendor. Don’t just trust them to give you objective advice on how good they are; there’s a great deal of hype in the APM market that can often cloud our understanding of a certain solution’s actual function. So, where do you start? Typically, it’s best to start your thinking as if you were the end user coming into your application and infrastructure stack. This means monitoring, measuring and understanding the real performance of your web-based or custom applications. You should start with the customer (external-facing) side and then work your way back in through the stack from a monitoring perspective. Next, monitor, measure and understand the performance metrics of the application itself. Here you’ll find critical capabilities, such as distributed transaction tracing and code profiling, to be critical to truly understand how all the application components relate from a performance perspective. Finally, while it’s essential to also know how your infrastructure components are performing, it’s critical to do so in full application performance context. This application-context infrastructure monitoring must encompass both performance instrumentation as well as all logs associated with your application and related infrastructure.

    Start small for quick success and to build a foundation from which to make APM more broadly successful for your organization. Start with one, or at a most a handful, of applications needing the greatest attention. Prove value and success and then ramp up adoption from there.

    In all cases, remember—unless you’re solely relying on serverless computing, with only microservice-based applications in containerized environments, you’ll need visibility across the three application architecture types: monolithic, SOA and microservices. Otherwise, you’re not getting all the information you need.

    It’s always been the goal of IT throughout all technology revolutions—whether it was mainframe, time-sharing, client-server or distributed, and whether it’s hybrid or full-on public cloud—to get a single pane of glass for operational management. True, full-stack APM delivers that view.

    — David Wagner

  • Best of 2019: Implementing Message Queue in Kubernetes

    Best of 2019: Implementing Message Queue in Kubernetes

    As we close out 2019, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the fourth in our weeklong series of the Best of 2019.

    The adoption of Kubernetes as enterprises’ tool of choice is increasing very rapidly. Consequently, the architectural consideration and operational requirements to support production environments have gained increasing attention. A major challenge to consider when planning a scalable microservices architecture (MSA) that is orchestrated by Kubernetes is how to manage the heavy traffic of messages in the system.

    After migrating from the monolith architecture to a microservices architecture or setting up a new MSA, each microservice holds its data model and is disengaged from the rest of the system. When scaling, it is observed that a project can grow to hundreds or more microservices, and the messaging traffic can become enormous in systems that generate millions of messages a day. Hence, there is a need for a new robust communication between the microservices to be established.

    Using Point-To-Point connectivity such as REST to solve the communication gap in Kubernetes can end up creating a complicated structure between the services. A consequence of this is the need for comprehensive maintenance by the development team each time service requirements are changed. This is where a messaging queue system comes in handy to take care of the messaging challenge in MSA and Kubernetes. Each service communicates with one focal point (message broker queue) in its own language and the message queue system is in charge to deliver the messages to the services which are waiting for it.

    To build a well-managed messaging solution for Kubernetes, the message queue system should be native to Kubernetes, support the relevant messaging patterns, robust and secured. Being native to Kubernetes is a critical parameter to achieving a healthy system in Kubernetes. It includes a simple and fast deployment to Kubernetes (and not outside of the Kubernetes cluster), low DevOps maintenance and well connected to Kubernetes ecosystem for logging, monitoring and tracking.

    Hybrid Cloud

    A hybrid cloud solution enables enterprises to make use of both on-premises and public cloud services. An advantage of a hybrid cloud is the flexibility it offers–allowing workloads to alternate between the two environments when capacity and costs change, for example. Sensitive workloads and data can be hosted in the private cloud or on-prem while less critical workloads are hosted in a public cloud. Regulatory requirements for data handling and storage can be provided in the private cloud. A commercial advantage of public cloud services is cost, both in terms of CapEx and OpEx, as the scalability it provides allows an organization to pay only for the resources it uses. Deploying message queue in Kubernetes provides the technology that allows the hybrid clouds to smoothly and transparently connect and interact.

    Use Cases

    There are many use cases for message queues. The message queue needs to support diversified messaging patterns, enabling flexibility in creating different use cases.

    Here are some of the common use cases a messaging queue system should support in Kubernetes.

    Multi-stage Pipeline

    The synchronous pattern is used when we need to process the messages in a coordinated way in a workflow. Pipeline use case allows processing messages in a sequence between services. Each service can be considered as a stage, and the message passed between all the stages in a sequence. In some cases where the message is lost or cannot be processed (for any reason), the dead-letter queue mechanism takes the message and process it in a pre-defined way.

    Job/Task Distributed Queue

    The A-synchronic pattern is used by some producers to many consumers when we need to distribute tasks/jobs between workers. In this use case, there is no need to coordinate between tasks. Each service is pulling messages from the queue to process it. The sequence of processing the messages is not important as each worker takes the task from the queue and process it in his own time.

    Figure 1: Tasks/Jobs Distributed Queue.

    Stream

    The A-synchronic pattern is used when we need to stream data from many external sources (big data, IoT) and process it in a dedicated service such as database, pipeline, machine learning, storage, etc. This case typically aggregates many producers to a small number of consumers. The order of messages is not important, but the delivery guarantee is important.

    Pub/Sub Real-Time

    The A-synchronic pattern is suitable for cases of a small number of producers sending real-time data to many consumers. A service acting as a publisher sends a message to a channel where a set of services subscribe to that channel and get the messages.

    Application Decoupling

    Connectivity between services such as edge, API, databases and storage act like a router, and message order is not important; timeout and sync between producers and consumers are important.

    Ease of Use

    One key feature of the microservices architecture is its ease of use. Deploying it saves your organization time and money by unifying development and operations workflows. The message queue system needs to be easy to use as well. Its ease of use and DevOps’ friendliness should minimize the need for dedicated experts and, at the same time, accelerate development and production cycles. While considering this, it’s important to ensure support in high volume messaging with low latency, efficient memory usage and fundamental messaging patterns (real-time pub/sub, request/reply and queue) are not compromised.

    Gradual Migration to Kubernetes

    When IT professionals evaluate the significant advantages of using the Kubernetes environment, they cannot ignore the operational requirements necessary to maintain the revenue-generating monolith infrastructure. Legacy systems also contain the processes and data related to the on-going business and are crucial for the service contingency.

    To support a gradual migration that keeps the business operation, the Kubernetes message queue must enable connectivity between the old and new environments. A bridge is required to connect the legacy side to IBM MQ, TIBCO, MSMQ or Kafka (just to mention a few popular enterprise solutions), to the Kubernetes message queue that allows a seamless bi-directional transposing messages between the services in the legacy monolith environment and the microservices-based deployment in the Kubernetes environment.

    The bridge installed in the legacy environment is “listening” to the MQ on behalf of the relevant services in the Kubernetes environment, ensuring the designated messages are transferred from the monolith to Kubernetes and vice versa. This bridging capability enables gradual migration by implementing a step-by-step replacement of components from the old environment or the creation of new services that can still connect with the legacy resources.

     

    Figure 2: An example of gradual migration from MSMQ on the on-premises environment to AKS.

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

    — Lior Nabat

  • Best of 2019: The Time Has Come for an Engineering Approach to DevOps

    Best of 2019: The Time Has Come for an Engineering Approach to DevOps

    As we close out 2019, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the third in our weeklong series of the Best of 2019.

    Do you want to know how to do DevOps? Are you doing DevOps but not satisfied with the results you are getting? DevOps is complex. It does not come with a prescription, installation guide, user’s manual or maintenance manual. It doesn’t even have a standard definition. How can anyone expect to get good results with DevOps without clear and definitive guidance? There are plenty of books that describe different aspects of DevOps and customer user stories, but up until now there has not been a book that frames DevOps as an engineering problem with a step-by-step engineering solution and a clear list of recommended engineering practices to guide implementers.

    My book, Engineering DevOps: From Chaos to Continuous Improvement … and Beyond, provides a step-by-step engineering prescription that can be followed by leaders and practitioners to understand, assess, define, implement, operationalize and evolve DevOps for their organization. It provides a unique collection of engineering practices and solutions for DevOps. By confining the scope of the content of the book to the level of engineering practices, the content is applicable to the widest possible range of implementations.

    This book was born out of my desire to help others to do DevOps, combined with a burning personal frustration. The frustration comes from hearing leaders and practitioners say, “We think we are doing DevOps, but we are not getting the business results we had expected.”

    There are many documented references, courses and other sources of information that explain a multitude of different aspects of DevOps, but there is not a comprehensive step-by-step prescriptive guide that details how to engineer a DevOps solution for any organization given any starting point.

    Engineering DevOps takes a strategic approach, applies engineering implementation discipline and focuses operational expertise to define and accomplish specific goals for each leg of your DevOps journey. This book guides the reader through a journey from defining an engineering strategy for DevOps to implementing The Three Ways of DevOps maturity using engineering practices: The First Way (called “Continuous Flow”) to The Second Way (called “Continuous Feedback”) and finally The Third Way (called “Continuous Improvement”). This book is deliberately intended to be a guide that will continue to be relevant over time as your specific DevOps, and DevOps more generally, evolves.

    Structure of this book

    This book is organized as an engineering reference guide presented in five parts as follows:

    Part I: What Is Engineering DevOps and Why Is It Important? is organized into three chapters. Chapter one, “What is Engineering DevOps?,” explains engineering concepts and terms used in this book that have proven to work with many clients I have encountered during my consulting experiences. My depiction of a DevOps Engineering Blueprint is presented for as a useful, practical “big-picture” reference for discussing engineering the major parts of DevOps. Chapter two, “Nine Pillars of DevOps,” describes a classification of DevOps practices that I have found to be useful characterization of DevOps engineering practices readily applied when engineering DevOps implementations. Chapter three, “Why Is Engineering DevOps Important?,” explains the benefits of taking an engineering approach to engineering DevOps.

    Part II: Engineering People, Processes and Technologies for DevOps provides a comprehensive explanation of recommended engineering practices for the higher levels of the DevOps Engineering Blueprint. DevOps transformations are not normally understood or applied using strict engineering principles. Engineering practices are presented in nine chapters. “How Should DevOps Be Engineered?” includes a discussion of DevOps Engineering Maturity Levels for each of the Three Dimensions (People, Process, and Technology), Twenty-Seven DevOps Engineering Critical Success Factors and Lean DevOps Value-Stream Pipeline Engineering.

    I describe recommended engineering practices for the top layers of the DevOps Engineering Blueprint in the next chapters, which include “Value-Stream Management (VSM),” “Application Release Automation (ARA),” “Version Management,” “Continuous Security (a.k.a. DevSecOps),” “Service Catalog,” “Governance,” “Site Reliability Engineering (SRE),” “Disaster Mitigation” and “Recovery.”

    Part III: Engineering Applications, Pipelines, and Infrastructures Engineered for DevOps provides a comprehensive explanation of recommended engineering practices for the lower levels of the DevOps Engineering Blueprint, presented in six chapters as follows: “DevOps Applications Engineering,” “CI/CD Pipelines Engineering,” “Elastic Infrastructure Engineering,” “Continuous Test Engineering,” “Continuous Monitoring Engineering” and “Continuous Delivery and Deployment Engineering.”

    Part IV: DevOps Seven-Step Transformation Engineering Blueprint provides a description and tools for my approach to realize and evolve DevOps. The seven steps are Visioning, Alignment, Assessment, Solution Engineering, Realization, Operationalize and Expansion. By using these tools, DevOps leaders and practitioners can create, implement, operate and expand their DevOps across the organization. The chapter goes further to explain how to evolve DevOps from a successful First Way DevOps (Continuous Flow) toward realizing more advanced Second Way (Continuous Feedback) and Third Way (Continuous Improvement) DevOps implementations. This part includes a discussion of “Beyond Continuous Improvement”—a look at emerging technologies shaping DevOps in the future, and how you can prepare your DevOps and yourself for the future. This part includes a discussion of how to set up an effective DevOps engineering training program that supports continuous learning of DevOps engineering skills needed to maintain and enhance DevOps.

    Part V: Appendices, Continuous Learning, and References includes materials and sources I have found most useful for engineering DevOps.

    To get a copy of my book “Engineering DevOps: From Chaos to Continuous Improvement … and Beyond,” or start reading for free, click here.

    — Marc Hornbeek

  • Predictions 2020: Application Trends, Opportunities and Challenges

    Predictions 2020: Application Trends, Opportunities and Challenges

    Without wheeling out all the usual clichés, 2019 has been another whirlwind of disruptive innovation and opportunity–with plenty of challenges to tackle and circumvent along the way.

    The threat landscape mutated with predictable unpredictability, multi-cloud app deployments are becoming mainstream fixtures and DevOps methodologies started exerting a newfound influence on business plans.

    The big question is what happens next? What anticipated app-centric trends will change the game and tear up the rule book (again)?

    Digital Transformation Takes Shape

    In 2020, we will see more organizations shift away from aspirational sloganeering to substantively embrace what can, and should be, a seismic step-change.

    Inevitably, business leaders will get more involved in application decisions designed to differentiate or provide unique customer experiences.

    Expect a new generation of applications that support the scaling and expansion of business’ digital models to emerge. This will include taking advantage of cloud-native infrastructures and driving automation through software development.

    Further down the line, digital transformation efforts will likely be AI-assisted, particularly as they leverage more advanced capabilities in application platforms, telemetry, data analytics and ML/AI technologies.

    End-to-end instrumentation will enable application services to emit telemetry and act on insights produced through AI-driven analytics. We anticipate that these distributed application services will improve performance, security, operability and adaptability, without significant development effort.

    The Rise of Application Capital

    Applications are now firmly established as the main conduit for companies to develop and deliver goods and services. They have become modern enterprises’ important assets.

    Even so, most still only have an approximate sense of how many applications they have, where they’re running or whether they’re under threat.

    This will soon change.

    To manage Application Capital effectively, it is essential to establish a company-wide strategy that sets policy and ensures compliance. This includes addressing how applications are built, acquired, deployed, managed, secured and retired. At a high level, there are six distinct and unavoidable steps that need to take place: build an inventory, assess the cyber risks, define application categories, identify the application services needed for specific activities, define deployment parameters and clarify roles and responsibilities.

    The primary aim of an application strategy should always be to enhance and secure all digital capabilities–even as their reach and influence shift and expand.

    DevOps’ Culture Club

    The technical minutiae DevOps methodologies and associated tools got a lot of publicity this year. 

    2020 will be all about getting the culture right, marrying theory with best practice and unlocking new levels of productivity without upsetting the operational apple cart.

    Culture is not optional. Team structure alone dramatically changes pipeline automation, with traditional single-function teams often falling behind their contemporary, DevOps-driven counterparts. 

    Consequently, we will see more collaborative team structures and alignment on key metrics that give NetOps additional means to focus on what the business requires: faster and more frequent deployments.

    DevOps has a 10-year head start on NetOps in navigating and overcoming obstacles around certain types of integration, tools and skillsets. Collaborative teams can explode the status quo by promoting standardization on tools that span from delivery to deployment (such as Jenkins and GitHub/GitLab).

    DevOps should not–and cannot–end with delivery. That means deployment functions–along with a complex pipeline of devices and application services–must be automated. This won’t happen without effective cultural realignment.

    The Data Center Is Alive and Kicking

    Conflating the adoption of SaaS with IaaS caused speculation that cloud was cannibalizing IT. Pundits warned that data centers would disappear. 

    The rumors were exaggerated. Data centers are still being built, expanded and run around the globe. The cloud hasn’t managed to–and likely never will–kill the data center.

    Early in 2019, an IDC executive told channel partners at the IGEL Disrupt conference that over 80% of companies they surveyed anticipated repatriating public cloud workloads. Security, visibility and performance remain common concerns.

    Repatriation-related opportunities include improving availability of multi-cloud operational tools and a push toward application architectures that rely on more portable technologies such as containers. 

    The data center is not dead. It’s just evolving. 

    Application Protection Challenges

    According to F5 Labs, the server-side language PHP–used for at least 80% of websites since 2013–will continue to supply rich, soft targets for hackers. Situational awareness is critical to mitigate both vulnerabilities and threats.

    Businesses are also realizing that applications encompass more than just the code they execute. Attention needs to be paid to everything that makes them tick, including architecture, configurations, other connectable assets and users. The prevalence of access attacks, such as phishing, are an obvious case in point.

    F5 Labs analysis of 2019 breach data confirms the need for risk-based security programs instead of perfunctory best practice poses or checklists. Organizations need to tailor controls to reflect the threats they actually face. The first step in any risk assessment is a substantive (and ongoing) inventory process.

    As ever, the industry will gradually incorporate emerging risks into business models. For example, cloud computing has gradually shifted from a bleeding-edge risk to a cornerstone of modern infrastructure. The risks associated with the cloud have either been mitigated or displaced to contractual risk in the form of service level agreements and audits. 

    API and You Know It

    The word is out. Application programming interfaces (APIs) can transform business models and directly generate revenue. Cybercriminals know this.

    More than ever, organizations need to focus on the API layer, particularly in terms of securing access to the business functions they represent.

    One of the biggest issues is overly broad permissions, which means attacks through the API can give bad actors visibility into everything within the application infrastructure. API calls are also prone to the usual web request pitfalls such as injections, credential brute force, parameter tampering and session snooping.

    Visibility is another major and pervasive problem. Organizations of every stripe–including IT vendors–have a notoriously poor track record of maintaining situational API awareness. 

    API security can be implemented directly in an application or, even better, in an API gateway. An API gateway can further protect APIs with capabilities such as rate limiting (to prevent denial of service attacks) and authorization. Authorization narrows access to APIs by allowing access to specific API calls to only specified clients, usually identified by tokens or API keys. An API gateway can also limit the HTTP methods used and log attempts to abuse other methods so you’re aware of attempted attacks.

    Appy New Year!

    All this is of course the tip of an increasingly interconnected iceberg. Any New Year’s resolution worth its salt should include a commitment to comprehensively master the development, deployment, operation and governance of application portfolio. The best way to do this, and to get visibility into the code-to-customer pathways for all applications, is to leverage a consistent set of multi-cloud application services. Here’s to a safe, innovative and transformational 2020!

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Vincent Lavergne

  • Moving Things Around: The Acquisition of Protego

    Moving Things Around: The Acquisition of Protego

    I received a note from Protego Labs’ vice president of marketing about Check Point Software acquiring Protego. We see a fair number of acquisition announcements, and usually don’t write about them–though we read them and stay abreast of industry happenings.

    I used to follow Check Point, and haven’t looked into what they’re doing in a while, so I followed through links to both organizations and looked at their products.

    I found myself becoming the wizard that some call Tim. But instead of “What is your name? What is your quest? What is your favorite color?” I was looking into “Where is your site? What are your products? What value do you add?” My beard is kept trimmed, more along the lines of a knight’s, so it makes sense I would ask different questions. As long as I’m not spouting “It’s just a flesh wound,” I figure I’m doing okay.

    First off, this merger makes sense. Protego does it for serverless and Check Point is doing their best to be where your code is running. Indeed, Protego probably needed a merger of some kind because all they do is serverless. Check Point’s Cloud Guard Dome 9, by contrast, will protect access rights and data for serverless, but doesn’t do what Protego does–keep an eye on the code. So this is a good fit.

    But it once again brings to light an interesting issue as you move things from DC to cloud A to cloud B to serverless. Where are your support functions? Networking, security, storage…These things need to be where the code is, but architectural options are more than they’ve been for decades. And the architectures are largely incompatible. Consider network functions for a physical-server based DC versus a VM DC, versus a Container DC, versus Cloud…You get the idea. The array of functionality and where it runs is different. Different in implementation and different in maintenance.

    This was a problem I (and others) pointed out when cloud started taking off: more work for ops, even if some of it is automated. Turns out ops, storage management and security all have more work, because all of those items are handled differently in the different architectures. And Protego had to focus on one to get it right, meaning they needed some kind of merger in the long run.

    So do you. Adding more and more work to ops–be it DevOps or traditional ops–is not the answer. A plan for standardizing is necessary.

    That is one of the big promises of containers, in my opinion. Not only are they more agile and easier to use in a DevOps environment, they are relatively standardized. Ops will still have more work if you’ve got apps in several of those architectures, but containers obfuscate some of the differences and allow standardized networking within the pod/node/group, for example.

    Some functionality just doesn’t fit into containers–you still need a physical network in the DC, or to configure the virtual network in a VPC to get traffic to/from your containers–but much of it does fit. Once at the pod/group, networking is virtual and the same regardless of where the containers are running. Which reduces overhead while making changes easier. The same is true for security, and increasingly for storage.

    There are great companies out there tackling these issues, and I’ll look at them on occasion. Right now, I know my former employer F5 Networks is working to solve the networking services/performance/security issues, and taking advantage of NGINX to handle some parts the core org traditionally hasn’t addressed. There are other companies, I just hear about that one more because I am still very close to some F5ers.

    It is worth planning for and certainly worth looking into more portable options, anything that lightens the load and keeps your great apps running. Keep kicking rear and spinning up apps.

    And don’t call me Tim.

    — Don Macvittie

  • Waging a Winning WAR in AWS

    Waging a Winning WAR in AWS

    Above all other security advice for enterprises working with Amazon Web Services (AWS), there is one resounding war cry: “Go to WAR.” WAR is an acronym meaning Well-Architected Review. It’s a powerful and proactive way to mitigate real risk with the AWS team and its partners. If you’re using AWS (or thinking about it) consider adding WAR to your security arsenal. It’s a well-kept secret starting to proliferate in the cloud industry for reasons you will find obvious after reading this article.

    AWS Promotes a Shared Responsibility Model

    When it comes to cloud environments, a common term that is often heard and used across all cloud service providers (CSPs) is “shared responsibility model.” This model most often dictates terms of Master Service Agreement with any potential CSP, be it a Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) model. The goal is to clearly identify and establish the security responsibilities that are shared between a CSP and cloud consumer. 

    As security experts, Wallarm advocates for the shared responsibility model. It is impossible for a cloud provider to provide 100% security for you, like in securing your customer’s data and access (you can see this in the AWS shared security model below). There are also enormous benefits to application and API security to having both the CSP and cloud consumer putting up a strong defense. All customers on AWS and other cloud infrastructures should be proactive agents in their cloud security. (See Securing Apps on AWS with Wallarm.)

    This visual image depicts how shared responsibility is distributed:

    It Starts with Well-Architected Frameworks for AWS Cloud Architects

    AWS Developed the Well-Architected Framework to help cloud architects build secure, high-performing, resilient and efficient infrastructure for their applications. Based on five pillars—operational excellence, security, reliability, performance efficiency and cost optimization—the framework provides a consistent approach for customers and partners to evaluate architectures and implement designs that will scale over time. 

    AWS’s Well-Architected Framework approach is built on the shared responsibility model that helps consumers and providers truly understand their portion of responsibilities, as outlined in the figure below.

    The framework was intended to be far more than an architected tool for AWS. It was designed as a sort of way of life and method of looking at your architecture to ensure resilient and consistent outcomes. 

    The Well-Architected Framework is a living set of best practices that AWS continuously updates. Every time you think about starting something new or changing something, use the five pillars to evaluate what you are proposing. This is where WAR comes in.

    Approaching the WAR of Cloud Security

    The WAR is a systematic approach to review your architecture—whether already in AWS, on-prem or even in other cloud providers. WAR is currently a set of 46 questions, which could shift in number since this is a living methodology. It is  aligned to the five pillars mentioned:

    • Security. 
    • Reliability.
    • Performance efficiency. 
    • Cost optimization.
    • Operational excellence. 

    Answering WAR questions helps identify which areas fall into three categories: 

    • Well-Architected.
    • Need Improvement.
    • Critical Issues.

    Critical issues should be remediated immediately. These are things such as not using multi-factor for your accounts or exposing data to the public. Need Improvement items should be looked at over a three to six month time period. 

    AWS recommends that you perform these reviews periodically (at least every six to 12 months) on each critical workload. Even items that are deemed Well-Architected today can change due to changes in your environment or new options that replace the way you are doing things today.

    How to Go About a WAR for AWS

    There are two key factors that must be considered before you think about conducting WAR on AWS:

    1. Architecture Complexity.
    2. Skill Level.

    We are going to look at some example cases on what combination of factors should encourage you to wage WAR, or not.

    Case 1: Highly complex architecture and expert skill set.

    If you have a highly complex architecture and an expert skill set, a hybrid approach is recommended.

    Meeting with an AWS representative at least once can be very helpful to pinpoint small, important things that are easily overlooked. For example, a focus on the business logic based infrastructure might obscure your view of a Critical Issue. 

    After the initial WAR exercise and importing the results within the AWS console, you could get away with repeating the same process internally with your highly skilled staff. Frequency of WARs depend on what you discover and the amount of resources available to you internally.

    Case 2: Highly complex architecture and novice skill set.

    When you are handling a highly complex architecture and do not have the bandwidth to understand the different pillars of the Well-Architected Framework, look for external help. Negotiating a good price with an AWS partner, is the best approach. 

    Cost concerns shouldn’t stop you from a WAR. The cost savings coming from a Well-Architected Review may justify the additional costs involved in engaging with an AWS partner consultant.

    Case 3: Less complex architecture and novice skill set.

    If you are fairly new to AWS and the complexity of your architecture is not too high, it is recommended to engage directly with AWS team. A WAR will help you understand how to handle disaster recovery, redundancy, failovers, etc. that are usually not taken into account with new teams. 

    Case 4: Less complex architecture and expert skill set.

    The only case when a do-it-yourself (DIY) approach is viable (yet optional) is when you have a low level or architectural complexity and expert level skill. 

    For a DIY WAR, you can use the AWS Well-Architected Tool, released in November of 2018, along with a user guide. Review the Well Architected Framework whitepaper and refer to the questions and best practices to conduct the review yourself.

    The Well-Architected Tool is already part of your AWS Console. It’s incredibly easy to use. There are great instructions and videos for each question. 

    Getting to know all the pillars by navigating the AWS resources is highly recommended. 

    The Process of WAR 

    The process of WAR is simple and not as tedious as you may worry. It starts with a questionnaire-based review. The review usually takes a couple of hours and is relatively painless. Whether you do it yourself, appoint an AWS partner or engage directly with the AWS team of experts, you will use the Well-Architected Tool to go through the 46 questions. At the end of the initial session, you can expect to gain a decent understanding of your current architecture and a very detailed report breaking down the Critical Issues and Need Improvement areas into actionable steps for improvement. Outside a DIY approach, you are likely to receive a detailed report identifying the gaps in all five pillars of WAR.

    Amazon is known for its fundamental principle of customer delight. This philosophy really comes alive with WAR as AWS representatives work with customers to help mitigate findings after a WAR. Often times, companies can obtain credit from AWS to fix critical issues identified during WAR. War can be done in multiple iterations, especially if several critical workloads are identified and taken into the scope of WAR.

    What Is a Critical Workload?  

    Each customer knows their business and what’s critical to their operations. That might be your customer portal processing all your orders. It might be the supply chain system driving your manufacturing processes. It might be your case management system used to ensure client work gets completed on time. The critical workload is what you identify as most critical to your operations for running, changing or growing your business.

    Various Lenses for a Stronger WAR-Time Vision

    AWS means it when they say “put on various lenses.” The WAR process is an ever-evolving process. AWS has expanded the WAR for some very specific use cases. AWS calls these “lenses”:  

    Each lens area is changing quickly and has different architecture best practices. This is a strong reason why relying exclusively on a CSP for cloud security is never a good idea. A constantly evolving threat landscape makes it critical to understand the necessity of shared responsibilities and what is at stake. 

    For the sake of understanding, let’s focus on one of the lenses: serverless.

    Serverless computing assumes the provider runs the code provided by the customer while completely taking care of the infrastructure and the environment itself. Serverless providers offer what is known as function as a service (FaaS) platforms. FaaS platforms execute code for the application logic, but remain completely stateless themselves, meaning they do not store data. AWS Lambda is the oldest and the most popular public cloud infrastructure serverless computing offering.

    Serverless lens reduces the attack surface. Because AWS takes the infrastructure concerns on itself in their entirety, there is no need to harden EC2 operating systems and configuring container. Also, because there are no data or state exposure to the data, compromise is limited. 

    What still need securing are the APIs to and from the functional computing and access control, including authentication. To secure these vulnerable areas, runtime tools—such as Wallarm’s AI-powered solutions—can enable serverless API security and apply the well-known Defense in Depth strategy.

    To augment WAR process with actionable application security steps and strong granular authentication practices, we recommend:

    1. Applying auto-configured, run-time API security for Defense in Depth.
    2. Integrating automated security testing into your build or continuous integration process.

    DAST: Dynamic Application Security Testing. DEV: Developer.

    WAF: Web Application Firewall. SEC: Security.

    FAST: Framework for Application Security Testing. OPS: Operations.

    CI/CD: Continuous Integration/Continuous Testing.

    Conclusion

    The AWS Well-Architected Framework will provide strategies to help you compare your workload against the best practices recommended in this article. It can also help you get guidance on producing stable and efficient systems, so you can focus on functional requirements and overall business.

    Start learning about WAR by downloading the AWS Well-Architected Framework whitepaper. If there is one thing you must do to best understand and operationalize your shared responsibility with your CSP, is to perform a WAR.

    — Kavya Pearlman

  • The Top Six Cloud Computing Trends of 2019

    The Top Six Cloud Computing Trends of 2019

    Cloud computing was one of the hottest topics in the technology and business media throughout 2019. This is no surprise as the cloud sector has been growing rapidly for the last few years. Synergy Research Group recently reported a 37% overall growth year-over-year in public cloud. They also note that it has taken just two years for the public IaaS and PaaS markets to double in size and their forecast shows them doubling again within the next three years.

    While steady growth was expected this year, a few trends of note stand out. When the experts look back at 2019, they will likely stress the following cloud computing trends shaped the year.

    Rise of the Enterprise Cloud Manager

    We recently did a study on ParkMyCloud users which showed that a growing proportion of company technical leads have cloud or the name of their cloud provider–such as AWS–in their job title. This indicates a growing degree of specialization for individuals who manage and architect cloud infrastructure. Whether called enterprise cloud manager, cloud architect or something similar, 2019 saw the rise of a specialized role to oversee and direct cloud operations.

    Consolidated Multi-Cloud Views

    As enterprises large and small continue to adopt and use more than one public cloud, we have seen a rapidly growing need for a consolidated multi-cloud view and ability to take actions across multiple clouds in 2019. Third-party tools that do this provide enterprises the ability to pick a single tool to orchestrate, manage, govern and optimize their hybrid and multi-cloud environments. Many customers also sight the need to simplify operations—native cloud provider tools are not always easy to use.

    Multi-Cloud Arrives

    Multi-cloud truly arrived in 2019 and will only grow in 2020. The majority of organizations now use multiple clouds. In fact, most studies suggest that more than 80% of enterprises have a multi-cloud strategy. Reasons cited include the need to avoid vendor lock-in, the ability to leverage the best in class cloud services from each cloud provider and application efficiency choices.

    More Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down operations and critical projects. Thus, the trend toward automation continued to expand in 2019.

    More Abstraction

    IT became more and more abstracted in 2019. This means container usage grew, along with models that allow developers to worry less and less about infrastructure (such as serverless and PaaS).

    Containers Became Mainstream

    Application containerization is more than just a new buzzword in cloud computing; it is changing the way in which resources are deployed into the cloud. More and more companies utilize container services such as Kubernetes and cloud native services such as EKS, AKS and GKS in 2019, 

    Business continued to move to the cloud in 2019 and the six trends described above showed that the sector is growing–sometimes in unpredictable ways. Next year will, no doubt, also contain some surprises. But the trend for expansion of the cloud and related services is unmistakable for the foreseeable future.

    — Jay Chapel