devopsy.kinsta.cloud

Category: DevOps Practice

  • Atomist Takes on Application Drift Management

    Atomist Takes on Application Drift Management

    Atomist today announced it is extending the capabilities of its software delivery automation platform to include drift management tools that make it easier to identify changes to code.

    Now in beta, that capability is based on an open source project dubbed Org Visualizer, which makes it possible to clone an entire project hosted in a GitHub repository via a single click and then visually inspect it.

    DevOps teams also can leverage a built-in Policy Manager to capture and track changes in code, define custom policies that automatically apply updates and automated actions and generate progress reports showing how close they are to achieving a target policy goal.

    Atomist CEO Rod Johnson said the reporting tools provide a visual representation of what’s occurring within an organization’s codebase to make it easier to identify both overly complex dependencies and vulnerabilities.

    The drift management tools are built on the software delivery machine (SDM) concept that lies at the heart of the company’s core platform, Johnson said. The Atomist platform is based on a domain model for software delivery constructed around an application programming interface (API) server and GraphQL, an open source data query and manipulation language. That approach eliminates the need to master, for example, complex YAML files to deliver software. The addition of the visualization tools not only make it easier to see what’s going on in the development environments, but they also make it easier to identify areas where technical debt in the form of bugs and vulnerabilities is building within an application development project, he noted.

    The sooner those issues are addressed, the more probable it becomes that DevOps teams will deploy reliable, secure code, rather than needing to update it or roll back the entire application, Johnson added.

    Although the Atomist platform is capable of working in any application environment, there’s a high correlation between organizations that have embraced microservices-based on containers and organizations looking to automate software delivery using the Atomist platform, Johnson said. Organizations that embrace microservices based on containers typically have a frequent need to update codebases in production environments, he noted, adding many organizations don’t know the impact that microservices updates have on the rest of the production environment.

    In general, there’s been a lot of DevOps progress when it comes to automating continuous integration within the context of application development project. However, automating the delivery of software has proven to be a more elusive goal. As the rate and amount of code being developed continues to accelerate, it’s now only a matter of time before software delivery automation becomes a more pressing issue. Manual deployment processes prone to errors only serve to aggravate application development and deployment backlog at a time when business leaders are demanding IT teams become more agile.

    At the very least, tools that enable DevOps teams to visualize the scope of the challenge ahead should help frame a realistic conversation about what’s truly achievable, given the current state of the codebase.

    — Mike Vizard

  • Agile QA at Scale: Software Testing Strategies for Enterprise Teams

    Agile QA at Scale: Software Testing Strategies for Enterprise Teams

    Change is hard; it’s a universal truth not many people would disagree with. When you’re forcing (or strongly encouraging) change in a group of people, it’s especially hard. Even if that group is small, there’s bound to be miscommunication, disagreement and other friction points that make the change hard to implement.

    Now, multiply those difficulties by a factor of five. Now 10, 20 and so forth. This is the challenge of growing and expanding an organization. While you need to bring more people on board to fuel your growth, build a better product or improve the leadership, you also need to manage the complexity introduced by a skyrocketing headcount.

    More and more teams are accepting the challenge of switching to agile QA because it saves time, improves team collaboration and results in a superior product in a consistent, repeatable way. But most of the how-to articles and strategy guides out there only focus on small teams. What about the enterprise team ready to make the switch?

    Let’s look at a few software testing strategies for enterprise teams who have—or are in the process of—adopting agile QA in their organization.

    Outline a QA Strategy that Is Scalable

    Scalability starts early. You don’t want to set off running with a strategy that doesn’t fit your current team or is unable to expand with your team as it grows in the future. It’s key to adopt an approach that is flexible in all areas, from the technical aspects (tools and infrastructure) to team hierarchy and how resources are managed. If you don’t have a QA expert in-house, you may consider hiring a QA vendor to mentor you on testing approach, scalability best practices and team structuring.

    Bring on the Right Skill Sets

    Know what your business priorities are, what types of skills and technical expertise those priorities require and hire the right team for the job. With a solid team in place, you can scale up or down as needed. It helps to bring in both generalists (people who can handle a bunch of different domains) and specialists (people with a niche focus or specialty area). As you grow, your rock-star engineers will, too—they’ll move into management roles, continuing to motivate, lead and challenge their direct reports.

    Choose Metrics that Make Sense

    If you don’t measure progress and team output, you won’t know when it’s time to scale—or in which area that scaling is required. Be sure to invest time and care into the process of defining your success metrics, as they’ll have big implications for how your team is structured and how it grows in the future. Also be aware many success metrics focus too narrowly on code coverage and the number of tests executed. These are important numbers, but not as important as the overall quality of the product, which should be your “North Star” metric.

    Automate What You Can

    One of the easiest ways to scale without immediately adding headcount is to invest in automation testing. By automating regression testing and other intensively manual tests, you can free up engineers to work on higher priority projects, save more of the team’s time and cut resourcing costs. Plus, automation can help improve the quality of the product by reducing the number of human errors.

    No experience with automation testing? There are QA vendors out there offering expert automation teams who can learn your product, culture and processes in no time flat.

    Monitor and Maintain

    If you can spare it, devoting headcount specifically to monitoring the errors and alerts that arise during testing can help expedite the rest of the team’s work. When engineers don’t have to go back and work on every little fix or patch, they can focus on driving through their higher priority workload. Nitpicking the small stuff just isn’t feasible at the enterprise level, especially if you’re employing gifted and talented engineers.

    Here’s What You Need to Know

    1. How to Scale Your QA Team Effectively
      • Involve QA as early as possible
      • Design effective test strategies
      • Focus less on narrow metrics; more on product quality
      • Switch to smaller, more frequent releases
      • Test based on real-world user experiences
    2. Attributes of Agile QA at Scale
      • Automation is a part of the process
      • Engineers take ownership of their modules
      • Quality is top priority (“North Star”) of the whole team
    3. Strategies for Scaling QA
      • Understanding business priorities
      • Building a skilled team that reflects those priorities
      • Creating a roadmap for troubleshooting quality issues
      • Implementing technical and managerial strategies that scale

    Wrapping Up

    Everyone knows change is hard, especially when it requires people to work differently, work harder or work together in ways that are new, inefficient (only at first) and potentially uncomfortable.

    Successfully scaling agile QA is one of the best ways to ensure you’re consistently delivering a quality product to market. No wonder why teams small, large and enterprise-level are taking on the challenge—and with these strategies, you can too.

    — Anand Ramakrishnan

  • Aspects of Machine Learning on the Edge

    Aspects of Machine Learning on the Edge

    Machine learning (ML) is hard. Making it work within the confined environment of an embedded device can easily become a quagmire unless we consider, and frequently revisit, the design and deployment aspects crucially affected by ML requirements. A bit of upfront planning makes the difference between project success and failure.

    For this article, our focus is on building commercial-grade applications with significant, or even dominant, ML components. Edge devices, especially ML enabled ones, don’t operate in isolation; they form just one element of a complex automated pipeline.

    You have a device, or better yet, an idea for one which will perform complex analytics, usually in something close to real time and deliver results as network traffic, user data displays, machine control or all three. The earlier you are in the design process, the better positioned you’ll be to adjust your hardware and software stack to match the ML requirements. The available tools (especially at the edge) are neither mature, nor general purpose. The more flexible you are, the better your odds of building a viable product.

    Let’s start by describing a hypothetical device and we’ll work through some ML considerations of the design. As we discuss the design, we’ll visit and revisit DevOps automations that go hand in hand with these other engineering processes.

    A Smart Security Camera

    For our design, let’s look at a networked security camera. As an IoT device, it’s continually connected to the internet. We’ll assume our device will have at least 4GB of SDRAM, a 64-bit ARM CPU and run an embedded Linux that supports an Anaconda Python distribution, OpenCV, DLIB and TensorFlow.

    Our ML related goals are first, recording and labeling interesting frames, and second, alerting security personnel to suspicious activity. We are constrained by various physical, environmental and cost factors. To make the best use of the available data, we’ll need to use ML to examine and classify multiple objects from every image frame. We’ll use a cloud service to handle the second goal, so here, ML on the edge concerns image recognition. How should we proceed?

    Process the Images in the Cloud?

    We’ll need to recognize various objects in the frames, such as people, faces, vehicles, etc. Each object set requires execution (inference) of an ML model, which produces a set of bounded, labeled objects. A typical camera will record about 30 frames per second. Couldn’t our camera just send that data to a cloud provider? Ignoring other considerations, this is about 2.5 million images/day; even at a deep discount this would be billed at about $1000 a day, and that’s for each recognition model applied. Clearly, we’ll need to make other choices.

    Let’s start by examining the raw input stream. Each raw 720p (standard HD 1280x720px) frame uses about 5MB, so if we were to send 30 frames/sec over the network we would need an incredible 1.5Gbps connection (about a terabyte every two hours). For full HD and higher, multiply this by four to 10 times. We will not be sending raw, uncompressed video. Our problem is our ML models will only work against individual image frames. Where should we make our trade-offs?

    Video produces vast amounts of data, but very little information in a given frame is new; this is why various compression techniques work extremely well, and raw data reductions of 100-1000x is typical. These reduced rates of 15 down to 1.5 Mbps is fairly reasonable, so perhaps we can do our ML inference using cloud services, as long as we host our own machine instances rather than paying for ML services. Depending on our workloads, we can expect to process 24×7 video for between $50 and $200 per month.

    Having decided to host our ML models in the cloud, we now need to manage a corresponding set of DevOps considerations. Do we have enough compute power to manage the service? How will we scale the workload as the number of edge machines increases? What are the storage and data retention policies? And of course, since we’re dealing with images of people, how will we manage privacy concerns and the associated legal and political ramifications.

    What should bias us toward more cloud processing?

    • Our initial development budget is more limited.
    • Our ML models have not been proven effective in limited processing/memory environments.
    • We need the flexibility to rapidly change the models we use for processing.
    • We know the network connectivity is robust and offline operation is not required.
    • Our budget for cloud services can significantly exceed the cost of our edge hardware.

    The choice between processing in the cloud, or on the edge is not a binary one. Designs can massively benefit from even limited edge computing; in some cases, simple detections (motion/vehicle/human/face) can be implemented on the edge to reduce cloud workloads by orders of magnitude with no loss in utility.

    Can We Do Most of the Work on the Edge?

    If we’re using Python with C library acceleration on our quad core ARM, simple ML models such as face detection (not recognition) may handle 10 to 20 frames/second, but 30/fps on anything like a full sized image will not be possible. Deeper, more complex models won’t fit into our limited RAM, and if they did fit, we could see inference times exceed a second per frame. We’re now faced with the realities of life on the edge: trade-offs.

    Once we’ve committed to placing our models into the edge device, we’ll need continuous integration (CI) and deployment services to support our product. These will let us train and retrain our models in the cloud, automate the process of validating improvements and produce the embedded code that updates the models in our target devices.

    Since we initially used models well suited to GPU based servers, can we just add a GPU to our device? In a word, yes, but with some very real costs. Adopting an alternate SoM with GPU support will provide a magnitude of improvement in inference performance, but will double or treble the unit cost and power consumption will increase. Such changes may incur significant non-recurring engineering as adjustments, rewrites or retraining of the model will be required to take advantage of the new hardware. Non-recurring engineering is a one shot cost associated with a change to a part, assembly or system.

    In some cases we can plug an Intel Movidius Neural Compute Stick (NCS) into a spare USB port and see 5x to 10x boost in per image rates. These are supported by the Intel OpenVINO toolkit, but there will be some development time to get things running and not every model can be made to work.

    The next tool in the box is Field Programmable Gate Arrays (FPGA) development. It’s a chore to incorporate these into our board design, but performance can be equal or better than GPUs (on some models), and power consumption is lower. The Intel OpenVINO Toolkit supports Arria and Stratix FPGAs for DNNs. Pricing can be prohibitive.

    Finally, if our device will be produced in large quantities, it can be worth a few million dollars of NRE to build an Application Specific Integrated Circuit (ASIC). The sunk cost of ASIC design can be huge, but the lower unit costs will make up for it. We’ll go this route only once our design has been proven, locked down and we are sure the market can take the volume needed to break even on these engineering costs. I should note architectural improvements in dataflow processing of DNNs in ASICs, such as Vivienne Sze’s work, show promise for dramatic improvements in weight, power consumption and cost. If you are planning for a longer term, don’t rule out these developments.

    What would make our edge processing easier?

    • Start with low footprint models such as TinyYOLO, MobileNet or SqueezeNet.
    • Accept lower frame rates for image processing in our design.
    • Evaluate the ML models with the hardware specifics and tool sets in mind, up front.
    • Provide automated DevOps services to update models in your devices.

    Building our ML models to run on edge devices will involve significant development costs. Tool chains do not install seamlessly, and it’s common to spend days to weeks tweaking the environments. Development and testing on these platforms tend to be slower and involve more manual steps than we’re used to in our DevOps environments.

    Running models on the edge will increase our DevOps complexity. Our cloud workload will be lower, but now we’ll include cross compilation, embedded code builds, download management of larger images and various additional test and validation stages. These will be on top of the training, load balancing, data retention, privacy and security issues we need to address for a cloud-only system.

    Conclusions

    What else will affect our choices here? The nature of the inputs can really matter. If our camera visualizes traffic on a busy roadway, or people in an airport terminal, we can expect almost every frame will contain something of interest; if we’re monitoring the bottom floor of a parking garage–not so much.

    To recap:

    • Cloud services for video rate ML are cost prohibitive.
    • Integrate DevOps early to complete your product support system.
    • Understand and characterize your input data by volume, scale and importance.
    • Recognize not every model can execute on edge hardware.
    • You have more choices in edge hardware than you thought.

    Although there are still challenges to building more intelligence into devices, it’s important to realize every year these constraints are fewer, the tools get better and the devices become more powerful. A compelling argument can be made that most data processing should occur as close to its source as possible.

    — John Fogarty

  • Weighing the Cost of Improper DevSecOps

    Weighing the Cost of Improper DevSecOps

    Simply put, data breaches are terrible news for companies. And, the costs associated with such attacks continue to escalate. A recent IBM-sponsored report found an average price of 3.92 million per breach.

    Not adapting security automation and vulnerability scanning into development pipelines could have a drastic effect not only on cost but workload efficiency and team morale. With these sorts of headaches, it’s vital to consider the repercussions for not adopting secure (and lean) armaments and auditing procedures.

    Can organizations adopt DevSecOps beyond the buzzword it has become? In this article, we’ll uncover some startling evidence on the state of Kubernetes vulnerabilities and discuss what companies can do to rectify.

    Trends in Kubernetes and Istio Vulnerabilities

    It’s astounding how much in DevOps is left exploitable. Secrets are routinely unknowingly left in the open due to human error. These are the most common gateways for attackers. Plugging these gaps is the first, albeit obvious, step.

    There’s proof of an epidemic, too. A recent study conducted by Alcide ran a live production analysis of over 500 cloud-native environments across the globe. According to their findings, “89% of deployment scans show companies are not using Kubernetes’ secrets resources, with secrets wired in the open.”

    This means the majority of Kubernetes environments share susceptible to data breaches in some form. Among the 5,000 scans run, the Alcide report found secrets are commonly left open in a few areas, including:

    • Workloads that had to connect to cloud resources that exist outside the cluster
    • AWS access keys to connect to those resources
    • Tokens for workloads that require API access to external databases
    • Credentials for S3 buckets

    Gaps in Best Practices for Kubernetes and Istio

    Kubernetes brings many nuances to the table. It’s a sophisticated system, with a wide range of use cases and cloud-native experiences. These require extensive auditing and compliance checks to safeguard deployment.

    According to Gadi Naor, CTO and co-founder of Alcide, Kubernetes requires a good level of expertise. However, “there is a knowledge gap that DevOps doesn’t have,“ said Naor.

    Much of this gap lies in Kubernetes secrets handling and network policies. On top of Kubernetes, service meshes are a next evolutionary leap. Istio, an architecture layer for creating network policies is ten-fold more complex, according to Naor.

    On network policy creation, “75% of the scanned deployments use workloads, which mount high vulnerability host file systems; while none of the surveyed environments show segmentation implementation using Kubernetes’ network policies,” stated the Alcide study.

    These are compelling platforms, but best practices must meet the growing number of potential attack vectors.

    Why You Should Approach CI and CD Security Separately

    Many pundits now link continuous integration (CI) and continuous deployment (CD) together as if they’re synonymous. However, they are separate concepts. Securing them, in the same manner, could decrease overall efficiency.

    Scanning all resources created in the CI phase against security auditing could waste time and resources. For example, if you’re standing images for CVEs and only deploy 20% of those images, that is a lot of wasted exercises.

    Rather than scanning all environments in the CI phase, Naor believes you should focus on scanning 100% of images for CD. Therefore, security tooling is leaner, and anything deployed will be assuredly safe.

    Takeaways on the Cost of Poor DevSecOps

    Infrastructure components such as Kubernetes and Istio are powerful allies to the DevOps minded teams. These environments do come with their nuanced security concerns, which must be addressed. Otherwise, the data breach price tag is high.

    To intercept system frailties before the black hats do, you must consider the following:

    • Scan for the Obvious: Utilize automation to discover secrets, keys, tokens, left in public repositories.
    • Scan in a Lean Way: Maintain a lean security environment that retains your engineer’s attention.
    • CI vs CD: Recognize the security nuances between integration versus deployment.
    • Add Auditing Tooling Strategically: Adopt compliance and auditing tooling that doesn’t create friction with existing developer workflows.

    As Naor said, “Don’t ignore the obvious stuff.”

    — Bill Doerrfeld

  • Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience

    Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience

    Here’s what I’ve noticed after spending several years in service management: DevOps is coming up more in the conversations I’m having with service desk leaders. Usually, these conversations start with one of the similar questions: DevOps is going to be the death of ITSM, correct? Alternatively, some consider DevOps as a challenge, and ITSM doesn’t seem so relevant because you don’t have in-house development going on.

    I always answer these questions in the same way: ITSM is relevant, and DevOps is not a threat to it. There’s more to it, however. ITSM professionals can still achieve their most relevant goal–excellent customer service.

    If you allow me a moment, I’d like to offer some background as to why excellent customer service is essential for every ITSM professional, then walk through some of the ideologies or frameworks used and how they interact. I’ll close this piece by discussing what radical transparency means in practice and how it can help you achieve an excellent customer experience.

    Some Background

    When discussing DevOps, we usually see three parts: Development, operations and the actual business. The business demands different things from both development and operations. Development teams are asked to push out code as fast as they can, and operations teams must keep the existing services available and make sure everything is stable. Development is trying to fulfill as many business needs as fast as they can, while the operations team is accountable if things go wrong.

    These might be extremes, but these are the traditional silos that have their expertise, priorities and goals, but there is no holistic overview. These internal organizations also use their way of working, based on a framework or ideology: DevOps tends to use agile, the business uses lean and ops focuses on ITIL. These ideologies can clash and compete at times.

    Because so much is happening with DevOps, we see significant developments. The speed of development and deployment is increasing, leading to additional continuous delivery advancements and technology implementations. The collaboration and breaking through walls between the development team and the operations team for deployment has come a long way within many organizations.

    Meanwhile, ITSM professionals face more and more challenges. Apart from the existing incident handling, they encounter incidents about newer, faster releases. Also, how are they supposed to deal with knowledge management, an already complicated process in itself? The increased speed of development makes it look as if they are always running behind. Getting out of that reactive approach is not getting easier.

    Customer experience and satisfaction is the number one priority in ITSM, creating quite the challenge. In ITSM, all input comes in: If things do not work at all or break down; if things do not work as expected; and if users need help to get things working. Good feedback also usually comes in via the service desk. When examining customer experience, there is a thin line in how fast you can go: If functionality is delivered too quickly, customers will not be able to use it. When delivered too slowly, customers will be unhappy about it as well.

    You can argue that a new silo comes into the picture–namely support. The support team keeps things up and running. Likewise, there are communication links between the customers and the other silos where they can filter bugs to development, info on any outages to operations and feedback on how the customer perceives the value of the functionalities to business.

    What if you don’t have in-house development? Well then, DevOps and the link with ITSM can be even more challenging, meaning you only have part of your DevOps and some of your support outsourced. For one application, perhaps you are relying on one or multiple vendors, but it might be the case that your vendor is dependent on another vendor.

    In other words, the process looks more like a plate of spaghetti than a smoothly laid smooth IT process. There are significant benefits to outsourcing, which is why we keep using outside vendors for some of our operations. In these cases, consider the shift of responsibility, the extra expertise, stability and continuity you gain. However, there are also downsides, such as loss of transparency.

    A Shift in Responsibility

    Shifting responsibility does not mean the same as a shift of accountability. Your ITSM team will still have to take ownership because even if you are not controlling everything. You have to be in control. In the end, you are still responsible for your customer experience and happiness. Customers do not want to wait two years for new features because the update of the vendor cannot take place for whatever reason. Also, it would be best if you had insight into what is going to happen for your users, and you need extra insight regarding how everything is working.

    Silos make this a challenge without outsourcing and are even more so the case when outsourcing these responsibilities. Before we move forward with solutions, let’s first take a step back and look at the frameworks and ideologies the different silos are using. As discussed, first, we have ITIL, typically used in operations.

    “ITIL is the most widely accepted approach to IT service management in the world. ITIL can help individuals and organizations use IT to realize business change, transformation, and growth,” stated Axelos on their website. It’s about aligning services to the needs of the business and supporting its processes.

    Next, we have lean, which is about maximizing customer value and minimizing waste. Lean is where value stream mapping comes in. You identify what works then look at how you can improve flow. Finally, agile, the cultural aspect of DevOps.

    At first sight, each of these processes seems contradictory, but actually, this is not the case. The key is using each of these principles correctly. For example, consider CAB, which comes out of ITIL. In many cases, the A in the acronym stands for “authorization” instead of “advisory.” Knowing that might make things much better and can open up the possibilities of automation, which is crucial to improving things.

    Likewise, some people tend to say that agile can never work in an ITSM context because it is against processes, but that’s also not true. Agile speaks to individuals and interactions over processes and tools, not without appropriate processes and tools. However, if you take a step back, you see they have more in common than you might think and some changes coming to ITIL4, for example, already address how to achieve a better correlation between the three.

    Let’s look at all of them together. Usually depicted as a horizontal value stream, but looking at it as a continuous loop, makes things a lot clearer for me.

    When you start in the business with the idea, take it through the design, code, build and test phase, then move over to the release and deploy and then we get into ITSM territory with the support and monitor stages. Where you see the blue line is where DevOps focuses mostly, so this is also where you witness the creation of a new silo: support (where ideologies or frameworks come in the picture).

    Radical Transparency

    So how do we break through these silos? Radical transparency. First of all, silos have to share their common purpose, which in the end is excellent customer experience. You can change it however you want; but in essence, that is what the business, development, operations and support all strive.

    To accomplish this, we first must know what impacts the customer experience.

    Let’s break it down: There are visible and invisible effects for the customer that can either be positive or negative. Visible results on the positive side will be features; on the negative side, defects. On the invisible side, positive things include architecture and process improvements. On the negative side, technical debt.

    For excellent customer experiences, we need to focus on the visible effects. Invisible effects must be worked on, too; if completely neglected, these will become visible at some point. The most prominent and the first focus should be on the visible effect. To do that, we need insight. If we all have the same set of information, often we all come to the same result. Getting to that same set of information requires radical transparency and also sharing information and insights.

    Shared Workload Tooling

    First disclaimer: When I talk about sharing tooling that does not necessarily mean using one tool. I will specify. I mentioned before that ITSM professionals have to know what is going to happen that might affect the customer experience. They have to be aware of which new versions are coming out and which customers are going to be or are on that version. For that reason, you need to share relevant information from your release orchestration tool to your ITSM tool. For instance, in our service management tool, we can see who is on which version via an automatic integration.

    That is a flow from DevOps through ITSM. The return flow also is essential. Any feedback that comes through your ITSM process regarding bugs has to flow back as well. So, for that, you need an integration between your ITSM and bug tracking tools. I also have seen some examples within the ITSM process where a Kanban board is used to improve collaboration between development, operations and support.

    Just making visible those tasks that impact customer experience and being able to follow up on the progress made by all stakeholders is so valuable. It also gives the support team the necessary insight to be able to communicate with the customer.

    If you are working with one or multiple vendors and dependencies there, you will want to include vendors in this as well. Moreover, that might mean you even have to tie in your and their ITSM tools.

    Another thing you want to share is customer satisfaction insights. First, measure satisfaction throughout the entire chain. That includes employee satisfaction, as well. We have seen the proof that employee satisfaction has a direct impact on customer satisfaction, so make sure you have all those data available and insightful.

    Knowledge Sharing

    Next up is sharing knowledge, which requires proper documentation. Think of federating knowledge into a knowledge base to make relevant information available to the right people. Make sure you have a good understanding of each other’s processes, and the impact they have on one another is essential. As an example, we had some challenges in collaboration with one of our hosting partners. When we sat down to discuss this with them, we found out some choices we had made in the deployment and support process, were not as reliable because we had assumed things about how the hardware had been set up and those assumptions were not correct.

    Excellent documentation and communication are key. If you have things outsourced, you want to make sure your vendor is the right partner, and you have a common understanding.

    Another important thing that should be shared is dashboards, where you can have a total overview of all parties involved and the impact they might have. You especially want to have visible what the effect is on the customer experience. It is valuable to have insight into all things that need your attention, but for your shared dashboard, focus on those things that are not going well and that have an impact on the customer experience.

    When you work with one or more suppliers, you want to make sure they are also using these dashboards and actively monitoring these. For you to be sure they use that, add that in your vendor selection criteria. The only way this works is if there is that radical transparency, where all parties involved have access to your vendors, development, operations, support, business and customers.

    Takeaways 

    Hopefully, because of this article, you’ve taken some additional perspective about where DevOps and ITSM come together, why the silos have to be broken down and how working with one or multiple vendors can be especially challenging. Also, hopefully, I’ve provided a bit of background on the various best practices, frameworks and ideologies most used and how they share commonalities. Radical transparency means breaking through the silos and how this can improve your customer experience.

    Finally, to sum it up:

    1. Make sure all parties have a common purpose and are doing everything to achieve that.
    2. Share relevant information. All words here are significant: share to achieve radical transparency, applicable because you don’t want to flood people with things that are not of use to them, and sharing too much may distract them too much. Provide just the relevant information so everyone can focus on the common purpose.
    3. If you do all that, you will produce better value for your customers, all for excellent customer experience.

    — Jeroen Boks

  • Out of Date: Cloud Anti-Trends of 2019

    Out of Date: Cloud Anti-Trends of 2019

    Let’s talk about 2019 cloud tech anti-trends. A lot of those anti-trends are nothing but cloud myths, which are still widely spread and talked about.

    In this article, we’ll take a look at some anti-trends and try to understand where’s the myth part in them.

    Private Cloud Is Not Popular Anymore

    According to the IDC research organization, by 2021, companies from around the world will spend more than half a billion dollars on cloud tech. This is two times more than in 2016. At the same time, there is a clear tendency: The public cloud workloads are growing, while the situation is exactly opposite for the private cloud. Cisco said, after three years 73% of the company’s applications will move to the public cloud, while just a year ago this figure was around 50%.

    Such a shift is partly caused by cloud providers, who offer users of public clouds more and more features that simplify the development of services. For example, tools that allow creating machine learning models, manage software deployment processes and analyze logs.

    That’s why many felt the active development of a public cloud meant the final decline of the private cloud niche. During his speech at a conference last year, Anthony Lai, senior vice president of the cloud-based division of NetApp said private clouds would “die out.”

    I wouldn’t expect the private cloud to disappear completely. The statement that it will cease to exist is only partly true. The private cloud may disappear as an independent unit, but it will remain part of the hybrid IT infrastructure.

    As noted in Gartner, 72% of companies in the world use a hybrid strategy. And it is expected this figure will grow. According to analysts from Market Research, the market for cloud object storage systems will reach six billion dollars by 2023. This will definitely spur further development of the hybrid IT infrastructure.

    One reason to use private clouds is predictable business processes.

    Yes, the public cloud offers flexible scaling. The company does not have to urgently buy new hardware if the load on the services has increased dramatically (for example, the application became a success and tons of new users came in). In this case, you can simply rent additional computing power. But if the load can be predicted (say, it is static) a private cloud is often enough.

    Also, a private cloud is often used to create object storage. Sure, object storage services are also available in the public cloud and a number of companies use them. Just a couple of years ago, Netflix migrated its entire infrastructure to the public cloud.

    However, not all companies need to build a distributed infrastructure as Netflix did. There are cases when companies have object storage in a private cloud because it already has an appropriate low-cost automated infrastructure. CERN is one of them. All the data generated by the Large Hadron Collider is stored in a private cloud.

    The IT-Infrastructure Market Is Oversaturated with Specialists

    Today, companies are actively abandoning their own infrastructure in favor of cloud solutions. That is why the need for in-house specialists engaged in its maintenance, gradually disappears. The IaaS provider takes on many issues related to the management and administration of the infrastructure, and the specialists need only ensure that everything is set up correctly.

    That is also why companies often abandon their own IT departments. At first glance, it seems this will gradually lead to instability in the labor market. Experts in the field of IT infrastructure, system administrators and data center operators will have to compete fiercely for the remaining jobs. But will they really have to?

    This does not mean such specialists have become completely unnecessary. In reality, in-house specialists simply change the focus of their activities. Most of the IT infrastructure administration tasks are now on IaaS and IaaS providers are now the ones who need and are actively fighting for such specialists.

    Even when you do use third-party solution, that is what happens sometimes:

    When customers start using intermix.io for the first time, they can see the set-up and configuration of their Amazon Redshift cluster in the context of their queries and workflows.

    At that point, customers experience one common reaction: Knowing what we know now, how would we set up our Redshift cluster had we do it all over again?

    The answer is not that straightforward.

    However, sometimes it happens that migration to the cloud stimulates the company to strengthen and develop the IT department more, attracting new cloud employees. These people study the cloud ecosystem, analyze the trends and evaluate how the transfer of an application to the cloud will affect the company’s work. If the company is already working with the cloud, then cloud specialists are also exploring new features of the current platform and exploring services that will benefit a business in the future.

    Clouds Don’t Hold New Technologies

    Four years ago, IBM listed seven cloud technologies to help businesses. The list includes IaaS/PaaS, private/hybrid cloud, test and application development environments, big data processing and disaster recovery solutions, along with data storage and backup systems.

    These technologies served as a standard technology stack for a long time. It was all developed with the efforts of IaaS providers. Therefore, there was an opinion that the cloud ecosystem was finally formed and no other use cases will be foreseen in the near future.

    New Directions Still Appear: The blockchain technology was born in 2008, gained worldwide popularity 8 years later and came to the cloud about a year ago. Based on the virtual infrastructure, a new direction has started to develop: Blockchain-as-a-Service (BaaS). In this case, the client receives a virtual environment prepared for working with blockchain technology. Users can create their own applications on the blockchain (for example, for processing financial transactions) and run them in a secure virtual environment.

    Quantum Computers: the most recent, fresh cloud trend. The quantum machine uses qubits instead of bits we are used to. Unlike bits, qubits can take the value of zero and one at the same time. Thus, a quantum machine can be in several states at once. The more qubits a quantum computer has, the faster it performs the tasks assigned to it. Imagine how much faster it can brute-force passwords or simulate chemical reactions.

    Quantum computers already have practical applications. IBM has recently opened access to its 20-qubit developments via the IBM Q cloud platform. And this year, Alibaba partnered with the Chinese Academy of Sciences to deploy an 11-qubit quantum device in the cloud. Quantum Computing as-a-service (QCaaS) opened the way for experiments on the infrastructure of providers and proved the cloud industry can adapt to the emergence of new technologies.

    Another Trend Is Fogging or Fog Computing: IT-industry experts are trying to solve the problem of delay in transferring data to the cloud. In the case of fogging, server components are not located in the centralized data center, but on the periphery, close to the end-user devices.

    In such an architecture, a main, large cloud still remains but has additional networking and computing layers: cloud, fog, edge. The Cloud (cloud layer, primary) solves expensive tasks for periphery machines (edge layer, end-user): data analysis, system logging, etc. The fog layer does local calculations in real-time to generate reports and send them to the central hub. This architecture improves the performance of the entire infrastructure by significantly (up to 10 times) reducing the delay in data exchange.

    To Sum It Up on Cloud Myth-Busting

    So, as with everything, rushing into extremes doesn’t help. That’s what we figured out:

    1. Even though public cloud seems to be a mainstream option, private cloud infrastructure still makes sense for certain use cases.
    2. Most of the IT infrastructure administration tasks are now on IaaS and IaaS providers are now the ones who need and are actively fighting for Engineers i.e. market is more than far away from being oversaturated with specialists.
    3. Clouds don’t hold new technologies. Did anyone really believe this one anyway?

    — Dmitrii Borodin

  • 4 Challenges OEMs Face When Implementing New Technology

    4 Challenges OEMs Face When Implementing New Technology

    Like many others, the manufacturing industry is moving to a subscription-based business model. This new way of doing business is being referred to as servitization and it is forcing manufacturers to no longer strictly sell new products, but instead sell access to and the outcome those products deliver. This is fundamentally changing the way manufacturers have traditionally done business and is not only encouraging a shift to subscription-based pricing models, but also Products-as-a-Service.

    As manufacturers implement the processes and resources necessary to make servitization a reality, implementing new technology will be key to success–laying the foundation for success today and in the future. More specifically, machine learning and predictive analytics will become especially important for predictive maintenance, process optimization and supply chain management. While there are opportunities to capture a significant competitive edge using these technologies, there are also significant challenges specific to the manufacturing industry. Some of these noteworthy challenges include:

    Efficient and Secure Data Connectivity

    Complex, capital equipment (think construction equipment, agricultural equipment or industrial machinery) is built and designed to last, on average, 30 to 40 years. As a result, these machines must be very reliable. Today, however, the majority of equipment in service has upwards of 20 to 30 years remaining in its lifespan. However, almost none of these products were built or designed for IoT connectivity–creating the challenge of retroactively fitting existing equipment with IoT-enabled parts.

    In addition, a majority of this equipment operates in some of the harshest and most rugged environments in the world. Whether it’s an electro-submersible pump 3,000 feet below the surface of the ocean or a mining truck in a remote mine with little to no cellular connectivity, efficiently connecting this type of equipment to collect relevant data is a difficult challenge and oftentimes cost prohibitive.

    Even if manufacturers manage to connect this equipment, there is an added challenge of doing it in a way that ensures cybersecurity. Rogue elements that could gain malicious access to this equipment could have serious safety and economic consequences–and could even implicate national security in some instances.

    Sparse Data

    Newer machine learning algorithms, such as Deep Learning and Recurrent Neural Nets, have been groundbreaking for capabilities like image and voice recognition. However, these algorithms are also very data hungry, requiring millions–if not billions–of similar data points from millions of users.

    Because complex industrial equipment is intended to last for decades, failures are generally rare. Think about it: There have been just a handful of actual engine failures during flights for the entire global commercial fleet, which amounts to nearly 30,000 aircraft. Assuming an average of 2.5 engines per plane, the global commercial aircraft engine fleet is less than 100,000. While certainly a large number by itself, it is relatively small when considering these engines vary greatly in design and thus any single engine type that could be modeled together would be even smaller.

    Manufacturers of industrial equipment or durable goods also tend to be reluctant to share data, especially if their competition could potentially benefit from it. The challenges of efficient connectivity, rare failures and relatively small numbers of similar equipment in a fleet leads to the sparse data problems in the Industrial IoT (IIoT) realm.

    Domain Expertise

    While domain expertise to successfully apply machine learning and predictive analytics is required in the consumer world, in the manufacturing space, it is much more critical. Machines and processes are designed using physics and engineering principles. And, the context in which machines operate and behave is very important for accurate training models and analyzing results. Without appropriate context, there becomes a “garbage in, garbage out” problem as sensor data and machines alone do not capture or provide any context. This is where domain experts who can make sense of historical data for accurate model training as well as interpreting results are critical.

    The impact of making an incorrect decision can have expensive–and sometimes catastrophic–results that aren’t seen in the consumer-facing domain. For example, re-routing an aircraft mid-flight could cost millions of dollars for an airline. If that decision is made because of bad data and an incorrect prediction, it would be a very costly mistake. For us as consumers, we have some aspect of domain expertise for problems in the consumer world, whereas a trained pool of engineers with the relevant design, operational and maintenance expertise is a very small pool. And this, combined with the problem of baby-boomer retirement where expertise is lost at a significant rate, there is a real challenge to capture the knowledge and best practices required to deliver value.

    Data Ownership

    Currently in the manufacturing sector, there aren’t industry standards for data security, ownership or accessibility. Currently, many manufacturers are wrestling with who owns and has access to the data. Is it the manufacturer who designs and builds the equipment? Or, is it the third-party entity that rents and operates it? Or, is it the financial entity that may be the legal owner? What about the supplier that provides a component that is part of a larger piece of equipment (e.g. an aircraft engine that works in conjunction with the aircraft, with each component manufactured by a different entity)?

    Manufacturers being risk-averse in nature, are being very conservative in interpreting and applying the myriad patchwork of regulations being brought in other industries, including data security standards. This is limiting them in adopting more connected processes and strategies. The industry must accelerate efforts to establish industry-wide standards as well as regulatory frameworks for data ownership, data-sharing, interoperability and testing of systems and end-to-end security to overcome the roadblocks for faster adoption of these technologies and realize the promised benefits.

    The shift to servitization will require manufacturers to completely re-think how they operate–new organization structures and skilled resources, new incentive models, new KPIs to measure success and new processes. They will have to become data-driven organizations investing in technologies to connect and track products, collect data and efficiently analyze massive amounts of operational and service data, using technologies like IoT, machine learning and predictive analytics. This will strain manufacturers’ existing organizations and IT infrastructures, necessitating investment in highly scalable, cloud-based solutions to lay the foundation for a successful future. Manufacturers that embrace these changes will be the winners, while others will struggle to stay relevant. In fact, the ones that can successfully adapt to these paradigm shifts will be able to gain significant competitive advantage and market share.

    — Vivek Shah

  • DORA Report: DevOps Maturity Levels Rise

    DORA Report: DevOps Maturity Levels Rise

    The annual DORA report on DevOps shows a marked increase among Elite performers compared to last year

    The DevOps Research and Assessment (DORA) arm of Google Cloud today published the results of an annual survey that suggests there have been marked gains in the level of DevOps maturity.

    The “2019 Accelerate State of DevOps Report,” an annual global survey of 31,000 IT professionals, finds 20% of the respondents now consider their organizations to be “Elite” DevOps performers, up from a comparatively paltry 7% a year ago.

    The Elite group reported their organizations routinely make multiple code deployments per day. By comparison, low performers reported deploying code somewhere between once per month and once per six months. The normalized annual deployment numbers range from 1,460 deploys per 365 days for the highest performers to seven deploys per year for low performers. Effectively, Elite performers deploy code 208 times more frequently than low performers, according to the DORA report.

    The report also finds Elite performers need less than a day of lead time to make a change to an application, compared to 2,555 hours for low performers, and Elite performers reported a change failure rate of 0% to 15%, compared to 46% to 60% for low performers. Finally, elite performers are able to recover from an incident 2,604 times faster than low performers.

    Nicole Forsgren, DORA Lead, Research and Strategy at Google Cloud, said the study makes it clear DevOps best practices are now crossing the proverbial chasm in IT. Organizations that are furthest along in making that transition tend to set up “communities of practice” within their organizations through which DevOps best practices are shared across teams, she noted. The DORA report also makes it clear elite performers automate and integrate tools more frequently into their toolchains on almost all dimensions.

    Forsgren said the study also makes it clear that the practice of slowing down the rate at which code is developed to achieve higher-quality application deployments is not nearly as effective as employing lighter-weight change processes to lower the amount of code getting deployed at any one time. Slowing down the rate at which code is developed and deployed is not a good strategy, she said, because as the amount of code that needs to get deployed at any time increases, reliance on heavyweight processes to deploy that code usually results in more errors being made. A lighter-weight approach provides the added benefit of reducing the amount of technical debt any organization is likely to incur at any stage of the DevOps process.

    The increased rate at which organizations are embracing best DevOps practices naturally coincides with the rise of more complex cloud-native applications. Most of those applications are being built using microservices that create a lot of dependencies within that application environment, with different development teams often working in isolation on specific microservices. The only way to manage that level of complexityeffectively is to embrace DevOps processes, noted Forsgren.

    In fact, the DORA report finds Elite performers are 24 times more likely to have met all cloud characteristics as defined by the National Institute for Standards and Technology (NIST) than low performers. Organizations that meet all essential cloud characteristics are 2.6 times more likely to be able to estimate the cost to operate software accurately. They also are twice as likely to be able to identify their most operationally expensive applications easily, and 1.65 times as likely to stay under their software operation budget, the study finds.

    Clearly, best DevOps practices is one of those rare IT gifts that simply keeps on giving.

    — Mike Vizard

  • Best Practices for Software Change Assessment

    Best Practices for Software Change Assessment

    Business spending on enterprise software has been on a constant rise over the past decade with 64% of businesses spending more on IT operations in 2018. It is estimated that in 2019, the number will reach $462 billion worldwide. This not only includes the procurement or development of new software and digital innovations, but also investments in modifications and upgrades.

    However, implementing software changes is no easy feat. It involves serious financial investments and staffing resources, which is why it is critical to get it right. A well-implemented change assessment is a key component of every software change project. This gives decision-makers an accurate and complete understanding of the impact of the software changes and identifies potential disruptions to specific departments, functions and processes.

    There are many ways to approach and implement software change assessment. These best practices can ensure a glitch-free software change rollout.

    Use a Comprehensive Discovery and Dependency Mapping Technology

     One of the disadvantages of the modern workplace across all industries is the emergence of information silos. They can hamper growth and efficiency and cause other problems, including redundancy of effort, stalled collaboration and other missed opportunities.

    In order to break these silos, efficient application discovery and dependency mapping is a crucial step in every software change project. Unfortunately, most businesses are failing miserably in this department. A Forrester survey revealed 56% of IT managers “do not have a complete view of dependencies between applications or between applications and infrastructure.”

    The same survey revealed 30% of the IT managers think that having a complete inventory of all enterprise hardware and software in use at their organizations is critical for IT efficiency. Ironically, 42% do not collect the necessary software data, while 39% are maintaining their inventory manually.

    The disadvantages of inadequate discovery and inefficient dependency mapping include low productivity, project delays, increased overhead costs and poor team morale, among others. A key step in solving this predicament is investing in the right discovery and dependency mapping technology, which can support a solid foundation for a software change initiative or any IT project for that matter.

    A reliable, agile software solution should provide both macro and micro views. The more granular, the better. Additionally, it should be able to give IT decision-makers a consolidated view of their application stack across multiple message queues, APIs, databases, unifying codes and languages.

    Use the Seven R’s of Change Management

    One thing IT managers should realize when assessing software change is, they’re not pioneering the process. Many organizations have done it and made mistakes along the way. Experts have used these mistakes and learnings to create roadmaps for others.

    One of the most well-established resources for IT change management is the Seven R’s of Change Management conceptualized by Information Technology Infrastructure Library–a set of detailed practices for IT service management. The seven Rs represent the following questions designed to help businesses make educated decisions on how to proceed with change requests.

    1. Who raised the change?
    2. What is the reason for the change?
    3. What return will the change deliver?
    4. What risks are there if we do or do not carry out the change?
    5. What resources will be required to perform this change?
    6. Who is responsible for this change being performed?
    7. What relationships are there between this and other changes?

    While these concepts are not exclusive to software change assessment, they provide a solid framework for businesses to identify noteworthy software change projects. This is especially helpful for organizations creating their software change assessment protocols from scratch.

    Never Skip Impact Analysis

    This is especially important for software vendors who are operating on tight budgets and strict deadlines. Software change impact analysis encompasses five major areas:

    • Identifying the impact of the change request on the software development project or on a business’ IT infrastructure.
    • Determining all software resources that need to be modified to implement the requested change.
    • Calculating the cost and manpower capital needed to perform the change request.
    • Ensuring the requested change complies with internal and external regulations.
    • Eliminating or minimizing any security risks associated with the change.

    To make sure businesses covers all the bases for any software change initiative, it’s best to use a checklist or template sourced either from the technology vendor or one their IT team put together, tailored to their needs.

    Not All Changes Are Created Equal

    Today’s ever-changing business landscape dictates business technology must evolve to keep up with an organization’s shifting needs. Software changes, when implemented strategically, can help businesses achieve new heights in productivity, efficiency and profitability.

    To ensure software changes serve this purpose, IT project managers need to implement an airtight software change assessment system. With the help of technology, checklists and well-established industry best practices, organizations can quickly outline a process that yields beneficial results in the end.

    — Aditya Sharma

  • Measuring Success in DevOps: Top Four DevOps KPIs

    Measuring Success in DevOps: Top Four DevOps KPIs

    There is no news in DevOps concept. Many companies have integrated DevOps to improve and accelerate software development and help drive their digital transformation, and that number continues to grow exponentially. There are now entire tool ecosystems, methodologies and transformation models—as well as endless resources—available to guide companies along the DevOps journey.

    But DevOps success can be difficult to measure. DevOps isn’t a formal framework; it’s more of a culture and a set of practices, and there is limited guidance available to ensure you’re doing it properly or accurately measuring your successes and failures. DevOps also looks different in every organization—no two DevOps shops will be the same.

    However, despite the nebulous definition of what a DevOps organization looks like, there are some core key performance indicators (KPIs) that should be common to all DevOps environments: asset management, monitoring, continuous integration/continuous deployment and continuous security.

    Asset Management

    In this context, asset management means measuring what is automated and how effectively it is controlled. It doesn’t matter if you are using tools such as Puppet, Chef, Ansible or Terraform; what matters is how effectively you use them. These tools allow you to automatically provision bare-metal or cloud assets, as well as join a load balancer and receive traffic. However, you can achieve similar results from Kubernetes or chaining lambda functions. Automation is really about controlling assets to achieve your business goals.

    Whether you’re using on-premises virtualization or cloud workloads, taking the time to streamline your processing cycles down to the minimum hardware required can significantly reduce monthly costs. The higher the percent of your servers, containers, services, etc. are automated, the less time you’ll spend fixing and maintaining your infrastructure. Some of your applications may be uniquely configured to your particular organization, and therefore cannot be automated. However, if applications cannot be automated, it might be time to retire them and build next-generation applications.

    Monitoring

    Should you be monitoring all of your resources? Yes. Should you also filter out the noise? Absolutely. Monitoring agents should be deployed to all of your servers, and if your PaaS tools and other providers have integrations, you should be using them and parsing out unneeded data. The only thing worse than not monitoring anything is monitoring everything without proper filtering.

    Good monitoring should always be coupled with utilizing the information acquired. Capturing logs, parsing them and using tools such as ELK, Datadog or Sumo Logic, for example, give you a large kit that can not only capture and glean useful information from a tremendous amount of data, but can also make decisions and perform predictive analyses. You might learn your stack is operating inefficiently, or not scaling fast enough during peak utilization periods.

    Disparate systems should be aggregated into a common tool, lest you spend valuable time combining information across systems or pulling information from data warehouses to get your insight. Let the tools do that work for you. You should also be using tools such as Logstash to pull and understand application, database and other logs in your stack for meaningful data. If not, you’re limiting your insight into the service’s health.

    Continuous Integration/Continuous Deployment

    Continuous integration and continuous deployment (CI/CD) is the difference between releasing software once a quarter (or year) and performing dozens of releases to production within a day.

    But it’s one of the most difficult indicators to measure, since every environment is different. It is important to understand how many code commits don’t make it past your integration environment. These blockages could be the result of poor programming practices, poor code quality or poor testing. However, if features stay in dev or integration for too long, there is surely an underlying issue. In most cases, it centers around automated testing.

    So, how do you measure good testing? This is one of the most difficult questions enterprises face, especially when automated testing is added after monolithic applications are already written. Essentially, good testing is about creating good business logic and integrating testing that meets most use cases, while covering each function and class. Immediate feedback on failed or successful tests expedites the automation process. The less automated testing is built, the more QA has to test by hand. Failing to integrate good business and integration testing slows down the entire CD part of the pipeline significantly. Also remember shooting for 100% test coverage is unrealistic—over 80% should be sufficient.

    It’s also important to remember applications that are not in a pipeline and must be manually tested will never keep up with the pace of cloud-born innovation. If you are dealing with a giant, monolithic legacy app, it’s time to design its replacement (starting with testing). Pipelines should also have notifications built into them, with chaining logic to react to failures. Tools such as Jenkins, CircleCI, TravisCI and most code repository solutions, such as GitLab, offer rich feature sets to aid in pipeline creation and management.

    Continuous Security

    The easiest way to ensure security compliance is to shift left and resolve security issues in the development stage. Too often, security is applied at production, which means it’s not part of the environment’s end-to-end process. Securing applications and networks at the development level will give you more confidence that applications will interoperate properly at the production level.

    After shifting left, make sure you continuously deploy and monitor your clusters, nodes and pods in a secure manner. Ideally, you have a tool that provides a real-time summary of your cluster’s compliance and security status by looking at workload security and governance checks, cluster worker node CIS Kubernetes Benchmark checks, cluster Ingress controller security best practices and istio security checks.

    DevOps Success Never Ends

    Success in measuring your core DevOps KPIs is not about getting to full automation immediately—it’s about understanding your biggest issues, continuously securing them and improving them over time. DevOps has no end; success requires continuously measuring your progress and improving your environment with the most effective and up-to-date tools. Take control, implement thorough and meaningful monitoring, deliver with confidence and do it securely.

    — Gadi Naor