devopsy.kinsta.cloud

Category: DevOps Practice

  • Low-Code Meets DevOps: A Smart Way to Manage Modern App Delivery Demands

    Low-Code Meets DevOps: A Smart Way to Manage Modern App Delivery Demands

    In a fast-moving and often fiercely competitive marketplace, companies need to embrace technology to stay relevant and drive growth. To this end, the business community is increasingly placing a high priority on digital transformation. In fact, more than 80% of organizations believe that digital transformation is crucial to business success.

    Digitally driven processes can power increased business speed and agility, as well as enhance competitive differentiation. Many organizations are now focusing on tools and methodologies that allow them to optimize more processes through accelerated internal application development efforts. Their goal is to be able to create, test and deploy the volume (and variety) of applications required to elevate performance and unlock more opportunities.

    In response to these growing needs for rapid app delivery, DevOps practices are evolving and becoming more critical to the success and agility of a business. According to a study conducted by Verified Market Research, the global DevOps market was valued at $3.62 billion in 2018 and is projected to reach USD 20.01 billion by 2026. Today, many businesses are combining DevOps approaches with low-code or no-code app development platforms, because these solutions provide them with the tools to build applications faster and more efficiently. This strategy helps to alleviate the immense pressures placed on developers today, by streamlining their workloads and responsibilities, while simultaneously enabling them to reduce their development cycle times.

    The Business Benefits of Fast, Agile Application Development

    Due to combining the roles, practices and culture of software developers and ITOps teams, DevOps allows a business to deploy apps more rapidly and with a higher degree of consistency. This is essential in organizations where there’s more pressure than ever before to deliver applications at the speed of internal and external demand.

    Often, the goal of adopting DevOps within a company is to reduce the tedious manual tasks that monopolize developers’ time and lead to app delivery backlogs. Solutions that help lighten and streamline the workload of DevOps–through automation and low-code development environments–are becoming more critical as a growing number of demands are being put on this still somewhat evolving, yet increasingly prioritized, team role and culture.

    Outlined below are a few examples of how low-code app development platforms can enhance the growing role of DevOps and improve the bottom line. This approach helps to:

    • Broaden the app development space to non-technical professionals: As mentioned before, low-code platforms enable a wider pool of less-technical users to work on and improve the speed at which applications can be built. Instead of the traditional app development team being solely responsible for a growing number of application requests, business users are now able to support digital transformation efforts by building and modifying their own processes, without writing complex lines of code.

    This approach makes the process of development more accessible to non-technical professionals. As a result, businesses can liberate their developers from routine coding work and redeploy these highly skilled individuals to more strategic projects that are critical to core business processes.

    • Facilitate faster application building: In addition to making application builds more accessible and less complex, the low-code environment also speeds up the entire development and deployment process. With this approach, companies can reduce development timelines from weeks or months to hours or days. Accelerating this cycle is crucial in any business that aims to outpace competitors.
    • Streamline consistent application deployment: Low-code platforms can integrate into toolchains (or a set of programming tools) that can automate the deployment of applications across various business environments. This ensures that apps created by non-developers can be deployed in the same manner as traditional, developer-based applications. This consistency provides a lower cost of ownership because it allows a low-code platform to more easily integrate into the business processes and workflows the organization already has in place. This minimizes the risk of disruption and irregularities.

    As businesses embrace innovation and elevate performance across the enterprise through agile, accelerated app delivery, the role and function of DevOps will continue to grow in influence and priority. Businesses that strategically leverage low-code solutions in combination with modern DevOps practices are likely to position themselves for growth, competitive differentiation and sustainable business success.

    — Holly Anderson

  • What Developers Must Know About Threat Modeling

    What Developers Must Know About Threat Modeling

    Threat modeling is a process that far few developers seem to pursue, but it is a process that helps you and your team to model all potential threats to your application. Essentially, threat modeling is your thinking through all of the potential threats against an application. Doing so is virtually as easy as putting together a list of threats in a structured manner that lets you assess any perceived risks, allowing you to formulate how you are going to respond to the threats.

    Ultimately, through threat modeling, you are optimizing network security by identifying objectives and vulnerabilities and creating measures to prevent the effects of threats to the system. Through this definition, anything described as a threat has the potential to be malicious to your organization and data systems; for example, incidental occurrences like the failure of a storage device–which can compromise the integrity of the entire enterprise.

    The reasons for threat monitoring may be pretty obvious, but any lack of progression here is quite common.

    Threats are one of the significant factors that led companies to spend $89.1 billion on enterprise security solutions. Gartner predicts threats will reach $96.3 billion by the end of 2018. According to Raytheon’s 2018 Study on Global Megatrends in Cybersecurity, 36% of senior IT and cyber professionals identified malicious or criminal insiders as a top cyber threat. Even with that knowledge, many organizations lack insider threat policies and policy enforcement tools, and they struggle to align security and IT responsibilities to tackle the threat effectively.

    Threat monitoring allows you the ability to determine which threats might exist for your application. Knowledge is power, and it’s always better to know beforehand what dangers might await you. Understanding these threats lets you decide whether you will accept the risk.

    For a threat to exist, there must be a combination of the following where the combined likelihood and impact are significant enough in which to do something. A framework for understanding threat modeling, includes: asking what you are working on, what might go wrong and what to do about it, as well as if a job is well done.

    According to the Open Web Application Security Project (OWASP), threat modeling is a process that lets you continually refine your processes based on what you have done so far: “Starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a consequence. Therefore, it’s generally best to start with the factors that make a lot of difference.”

    Those steps include assessment scope, identity threat agents, existing countermeasures, identifying vulnerabilities, prioritizing identified risks and identifying countermeasures to reduce the threat.

    In the assessment scope, you’ve got to understand the price of what’s at stake. Identifying tangible assets, such as databases of information or sensitive files, is usually straightforward, and realizes the capabilities provided by the application.

    Next, identify possible threats or attacks. A crucial part of the threat model is characterizing different groups of people who might be able to attack your application–this may include insiders and outsiders, performing both inadvertent mistakes and malicious attacks. During this phase of development, consider existing countermeasures that allow you to determine what possible exploitable vulnerabilities exist that must be addressed. Through your search, look for weaknesses and connect any attacks you’ve identified to the negative consequences you’ve identified.

    When identified, risk management can be prioritized. For each threat, determine possible outcomes and the impact of those to understand how to mitigate these issues. Next, look for ways to reduce any future risks.

    While many of the threats might appear to be security related, many others have more natural explanations. Threat assessments can include power outages or even a flooded server room. These and other factors can lead to severe threats to your organization.

    When to Model the Threat?

    Threat modeling is often best at the beginning of a project, but it’s better to conduct a threat modeling project halfway through a project or even at the end than not at all. Threat modeling at the end of a project can have benefits, such as understanding the architecture and how data flows through it. However, threat monitoring at the end of a project can lead to finding more work may be required to fix poor design decisions not caught at the beginning.

    For those entering into threat modeling, conduct your first session on an existing project, letting you experiment with a threat modeling session so that you can familiarize yourself with everything required. This way, you’ll be better prepared to analyze all assets and flow of data to assess the risks. Once the process is pounded out, you’ll have a better chance of succeeding in your threat modeling of a new project. You’ll also be able to better prepare for threats that may exist in the design phase of the project. From here, over time, you’ll begin to take into account threats during the initial design of a new feature.

    Approaching the Threat Model

    Each method of approach depends on the organization and its goals. Large organizations usually have previously established processes for threat modeling. Smaller organizations new to threat modeling can begin by hiring in experience to initiate the task or seeking outside support from experts or those who can advise the program.

    Next, you need to understand who the users are within the system–regular users, administrators, outsourced contractors and perhaps hackers with apps or other tools looking for vulnerabilities within your network. There are also other actors, including disgruntled former employees.

    Defining the user actors is important since missing a group can mean you might be missing an entire category of threats. Also, consider the various types of hackers or groups of hackers in your models.

    Data and Information Flows

    At this point in the threat modeling process, track each of the various data flows running through the system. For each of these, you need to know where the data goes. What does it interact with or encounter along the way? Then look to identify where data can leak or where it might be exposed. More data components create more opportunities for a hacker to gain access to the information.

    Individual data means the information flows differently based on the architecture and the specific situation. One example might include a request from a user’s browser where the cookie is sent through and interacts multiple components as it does.

    For each data flow, search opportunities for any actors to gain hold of valuable information. If anything makes you frown, step back through the process and move that threat through until you can mitigate the frowning moment.

    Threat List Complete

    When the threat list is observed and complete, prioritize the list from very unlikely to improbable to not likely. No matter the probability of the risk, work through the risk as a real possibility. Do so to consider the real impact of the threat and what it may mean to the organization. Is the company going to crash and burn completely? Will every bit of data get pulled into a ransom situation? Place a number or priority of the impact, such as low, medium and high.

    When you have your risk list, manage the risks by:

    1. Accepting: If the risk is quite low, accept the potential impact. It’s also possible you’ll find the potential negative user impact is more important. You can also reassess later.
    2. Transferring: Perhaps another team is responsible for managing a particular risk. If that team can pick up the defense easily, outsource it.
    3. Avoiding: Don’t do this. If you must, consider complete structural changes to your data flows to avoid altogether avoiding risk. This might mean architectural changes are required or killing a particular feature altogether so as not to avoid danger.
    4. Reducing: Take actions to lower the risk by lowering the likelihood or impact of the risk. You may need to take multiple steps to reduce the threat. No matter the action, effort is required to reduce the risk.

    After threat modeling is complete, don’t stop. Keep working because threats and actors change. List all potential issues or risks that must be addressed and work them into your plan.

    Finally, remember you should be careful with whom you share your threat modeling plan. You never know where that information might end up otherwise, or who might be a threat to your organization and its data.

    One last note: The final result and usefulness of threat modeling depend almost entirely on the parameters established. Defining the values for the probability of a threat and impact may be subjective, but let your experience, input from colleagues and experts, and your gut guide you.

    — Jeroen Boks

  • Optimism Matters and so Does a Sense of Wonder

    Optimism Matters and so Does a Sense of Wonder

    I’m a terrible video game player. For as much fun as people have with me at the table for Table Top RPGs (TTRPGs), I’m a pain when playing video games.

    As a guy with a masters in computer science, and years of experience ranging from embedded drivers to enterprise architecture, I see bugs or bad design decisions in video games and they tweak my sense of right and just. Ask my wife and youngest about playing Fortnite with me, you’ll get an earful. My wife uses her masters to analyze what could have happened in the code, and why it’s understandable. I fume and say “Yeah, well the code–not me, not the other guy–just eliminated me.”

    In short, I’m jaded where video games are concerned. As a casual gamer, I see the bad even while the good all around is rocking–EPIC devs, you’re doing a great job, particularly with the rate of change the game sees. Gamer rage is about the occasional oddity like getting stuck waist deep in the snow. Or about things beyond your control, like Skill Based Matchmaking that isn’t.

    I’ve noticed a trend in the portions of DevOps that I keep an eye on lately–fatigue. A sense that the change is non-stop, and the volume will just keep increasing. It only makes sense, we’re knee deep in sea change and new terms, products and processes seem to crop up on a daily basis. It can be wearing. Just looking at requirements for jobs–there is the persistent joke about 2000 years’ experience in Jenkins for a reason–it shows a fractured and constantly changing environment that begets unrealistic expectations.

    This has a tendency to make people jaded about new technologies and techniques. After all, Agile and DevOps have brought a huge return on investment, the law of diminishing returns might be kicking in, right? And lots of new shiny have turned out to be smoke and mirrors.

    The thing is, the rate of change in DevOps is still moving so fast because there is still more to gain. Continuous optimization, aka AIOps, is cool and promises a lot. Automated testing is still ramping up, even though automation of build tests is solid in most environments. Other kinds of testing (security, regression, live and even A/B) are still lagging, and test automation is offering help.

    What we need to do is try to keep that sense of hopefulness that we embarked on DevOps with. New tools might give us an appreciable ROI. They might free up time for time-constrained teams, which is the best ROI you can hope for. New processes might address shortcomings in existing ones. Will new tools and techniques always pan out? No, your environment is unique so even popular tools or techniques might not be best fit for your particular organization/apps. That’s okay, keep poking around at what’s new and remember the wins.

    I’ve got like a 4% win rate in Fortnite. Those other 96 games out of a hundred? All learning experiences to (hopefully) increase my win rate. Same with evaluating new tools. The failures feed the successes. It’s far easier to go “Product X didn’t work for us, and this is very much like it. Let’s look closely before even trying a pilot.”

    While there are more people in IT these days by conscious career choice, the bulk of us are still here because of the wonder moments–first time you got code to compile, spun up a cloud instance, figured out network segmentation or divided physical disk into partitions. The same sense of new and exciting should be brought to the current set of changing technologies, while still rock-starring your job. After all, it is some pretty astounding stuff we’re getting to play with every day.

    Maybe I’ll take my own advice, chill a bit when playing video games. After all, that’s another space that has jumped light-years in quality and availability.

    — Don Macvittie

  • From Automated Cloud Deployment to Progressive Delivery

    From Automated Cloud Deployment to Progressive Delivery

    Your team is on its agile journey and you can more or less track a deployment from a story, through git commits, to an automated builder, to an artifact repository, into a container and then onto the cloud. Or, in fact, any other of the many valid variants that lead you to believe your deployments are largely automated. What you can point to is a business request comes in and the result is a service or a new app. Your purview seems to stop before your users can even respond though. Is that good enough?

    Let’s go back to the early idea of a release. It was a collection of all the features and fixes the loudest stakeholders had persuaded the product owner to put at the top of the story list. A date was promised, but QA was late, and the persistent stakeholders squeezed a little more juice out of a story. Then it was stuffed into a ball and delivered to your servers overnight, lest anyone notice. The next day, the developers had to deal with the fallout as the support queues grew with confused users.

    While developers were getting the hang of the agile notion of automated deployment, the release lifecycle did pretty much end with a deployment going live. This gave certainty that what had been built and placed in the artifact repository was the same thing the testers had seen in the staging environment. And it also had the changes Jira said it had.

    This type of release was very much like a birthday present. Your uncle talked to your dad briefly, without your knowledge, and agreed you really would benefit from a new pair of socks. Then these were delivered on the day with the receipt in the bag, just in case you needed to take them back.

    The first evolution came with the concept that a release wasn’t exactly synonymous with a deployment. Finally, the end-user’s perspective nudged its way into corporate release strategy–updates could be deployed without necessarily impinging directly on every user. What if there were two identical release environments with clever network switching, meaning only one was truly live? This type of flip-flop arrangement (sometimes referred to as blue/green deployment) allowed changes to be tested internally in a realistic environment before going live.

    It was the advertising industry that prompted the idea of A/B testing. Instead of guessing one variation of a campaign might be superior to another, the surprisingly scientific method of using a controlled sample and a variation was used on audiences to see which they preferred. In the digital age, it is possible to deploy two variations of the same release to different server sets. This might mean each user session could be using either release. It would then be necessary to associate the resulting click-throughs, or whatever success measurement is chosen, to the specific release flavor. The worth of this kind of experimentation was only as good as the question you asked, but it was at least observing real user interaction.

    Moving on, DevOps environments began to use more feature flags or toggles. These were code paths that could deliver feature changes in live servers, controlled through configuration changes. This reduced the need to re-deploy to make certain changes. Release minded teams were coalescing around configuration, as opposed to just code. Whereas code once compiled and built was locked away in unreadable artifact files–a larger stakeholder community could administer configuration files, usually encoded in English. This helped to keep the feature changes closer to the stakeholders and less likely to slip back into silos.

    As a more defined understanding of delivery arrived, so did the understanding of the user community. It used to be the case that a user was a one-line entry in a database. Even firms whose business is not mining their user’s data understand there are different sets of users for products and services.

    Traditionally, there has always been internal users or beta testers–those within the firm whose job is to check the bits they understand, or are responsible for, are working as expected. Then outside the firewall, there are the tech savvy community who actively want the latest updates. These guys report bugs and often compare your product with the competition, perhaps using both. This audience will not lose their marbles if you deliver a bug to them. More to the point, they will notice rapidly–perhaps telling everyone on social media–about your failings.

    The disengaged users who may only have the free version or tier of your product come next. These people are more likely to work on impressions and are best not disappointed. They are also unlikely to be keen on updates. Finally, the large core of solid users who pay their way, just want things to work and need to understand a path to continuity will already appreciate the software and will understand the roadmap by osmosis. These will probably include your biggest users, too. Of course, if you have no way of distinguishing your users all the above is moot.

    With services sitting on a public cloud and CDN like edge services such as CloudFront, the ability to release by territory is much more straightforward. This is also increasingly necessary for legal reasons–EU regulations, for example. This allows for tactical releases to communities in different time zones and sizes. The practice of deploying changed services to a small group for risk mitigation, or “canarying,” is another method that takes advantage of smart routing. This requires the ability to quickly observe and rollback releases though.

    Today, most software has some degree of dark launch that restricts the visibility of a release to the appropriate community, until all is well. In this sense, a progressive delivery (defined as “continuous delivery with fine-grained control over the blast radius” by James Governor) can be seen as the virus-like spreading of your software or services from your development teams’ laptops to the last user.

    Observing service use is simply part of the core concern of virtually every company in the tech space. From this perspective, progressive delivery changes the way to see your development team as mere builders to user fulfillment specialists, which of course, they always were.

    The future will undoubtedly involve increasingly customer-driven releases, which goes hand in hand with the increasing use of data science to study user communities and their exhaust. The important take away is to make sure your team is reaching further to the right-hand side of the product journey, and keep the user’s reaction to what you make as a larger part of your sensory input. Think more about constant small changes and less about ceremonial releases.

    — David Eastman

  • DevOps Enterprise Summit Las Vegas 2019 Programming Highlights: What I’m Looking Forward To

    DevOps Enterprise Summit Las Vegas 2019 Programming Highlights: What I’m Looking Forward To

    I am so excited about the upcoming DevOps Enterprise Summit (DOES) Las Vegas. As a programming committee, we seek to make each event better than the last, as measured by how much we learn and how it helps enable the DevOps Enterprise community to achieve their goals.

    As a programming committee, we thought London 2019 was our best conference yet (almost unanimously), which poses a challenge of how could we possibly do better—but I’ve found over the last several years that this is doable, mostly by being very explicit about what challenges across our community we want to help to overcome.

    This year, we focused on the following areas, and I think you’ll find the upcoming conference does an amazing job of addressing them:

    • Experience reports of technology leaders presenting with even more senior business leaders.
    • Overcoming obstacles in security and compliance.
    • Experience reports and subject matter experts in the areas of data science and data initiatives.

    Reviewing this post, I’m finding the number of amazing stories being presented is so good that it’s incredibly difficult to pick which ones to mention here. But, the following speakers really stood out to me, because they’re so different than those from previous years:

    • David Almeda, chief people officer at Kronos: I was blown away when I saw him present. He talked about how one of their top strategic goals was to attract and retain great talent—the result was Kronos being named as one of the top 100 best places to work by both Fortune Magazine and Glassdoor, enabling then to support continued growth, innovation and profitability. He’ll be teaching us the value of employee engagement, and how the top levels of leadership view it.
    • Andre Martin, VP and chief learning officer at Google: Until recently, Dr. Martin was chief learning officer at Target, and before that, at NIKE. He will be sharing what his charter was in those roles, why those organizations created his role in the first place and how it could advance the mission of the DevOps Enterprise community.
    • The Big Four Auditor panel: In this amazing panel, we have four distinguished experts who support the audit practice.  We will be busting the most commonly heard myths and objections about “why DevOps can’t work here,” such as why DevOps can’t be done in regulated industry, why separation of duties prevents DevOps and many more. The four auditors are: Yosef Levine from Deloitte, Michael Wolf from KPMG, Matt Bonser from PwC and Pierre Fourie from Ernst & Young. They will be hosting two Ask An Auditor Anything workshops, facilitated by Dr. Tapabrata Pal and Sam Guckenheimer. This is an opportunity to anonymously ask questions about the audit process with some of the best experts in the space.

    I attended a smaller version of this session in London and I thought it was incredible and truly notable.  This one promises to be a landmark moment for the DevOps Enterprise community.

    Without a doubt, the programming committee has worked hard to create a high learning experience filled with technology leaders pioneering the business practices that will surely be commonplace within a decade. This, combined with experts from the domains that we’re drawing upon to help achieve our goals–along with exciting networking opportunities each day of the event–has helped us establish an industry forum for exchanging insights and information we need as a community.

    I hope you’ll join us in Las Vegas, and that you’re as delighted by the program as we are! In my career, I have grown to love conferences and have benefited so much from them. And yet, this conference is still my favorite. I never learn as much in such a short period than when I’m at DOES.

    Acknowledgements and Changes from Last Year

    I want to thank everyone for submitting a proposal to DOES for Vegas 2019. I personally appreciate and recognize the effort required to prepare your submissions. And I know because I still spend a lot of time preparing and submitting proposed abstracts.

    This year was the most difficult selection process for the programming committee ever, especially when so many are friends and people whose work we all respect so highly.

    To explain how we made decisions, I want to frame everything in terms of the conference programming objectives. Broadly speaking, here are the number of talk slots we reserved for each programming objectives:

    Talk Track Subject Areas Slots
    Experience Reports: New 12
    Experience Reports: Repeat 6
    Spanning Business/Tech Divide 9
    Next Gen Ops 8
    Overcoming old ways of working 7
    Subject Matter Experts 7
    Dynamic Learning Organizations 5
    Leadership Lessons, Transformational Leadership 3
    Other 4
    Total 65

    One thing that you should notice right away is every track only has a few slots. Another thing you are probably unaware of is we had more speaking submissions than ever before–it blows my mind just thinking about it.

    Evolving Programming Objectives

    In addition to the amazing response we received for this year’s call for presentations, we also worked to address some feedback from 2018 that “some talks sounded the same as last year.” So, we reviewed the talks again, and observed that some of the repeat speakers we invited didn’t have a lot of change since the last time they spoke. As a result, we’ve done two things:

    1. We’ve nearly halved the number of speaker slots for repeat speakers (see stats below)
      • 45% of repeat speakers (Vegas 2018)
      • 27% of repeat speakers (Vegas 2019)
    2. We invited repeat speakers who have a large change to report, or a different perspective to share (e.g., a different co-presenter from another business area), etc.

    In general, our top-level goal every year is to help technology leaders succeed in transforming their organizations—both by increasing the likelihood of their success and accelerating the rate of adoption of DevOps principles and practices by focusing on the following talk tracks and subject areas listed above.

    We aim to fulfill this goal through speaker presentations, both from technology leaders and/or subject matter experts from those domains. We also do this through less structured networking sessions where attendees can find other people who are tackling similar challenges or want to learn more about a particular area of interest.

    New Experience Reports

    One of the hallmarks of DOES is our program focuses on spotlighting real world experience reports, straight from the mouths of those who are driving enterprise-scale transformation. As adult learners, and as leaders, there are few (if any) better ways to learn than watching how other people in similar situations solve their problems.

    Besides enabling learning, experience reports serve another important goal—they help us as leaders negate objections that “DevOps can’t be done here.” I’m happy to say over the past six years, we’ve assembled a growing library of 250 experience reports from some of the most recognized brands around the world. As a whole, it shows DevOps principles and patterns are universal across nearly every industry vertical today. Some of the new experience reports I cannot wait to hear in October include:

    • Heather Mickman (VP platform engineering) and David Cherryhomes (VP, IT), UnitedHealth Group: Heather and David will be talking about their amazing work transforming business and technology at UHG, the largest healthcare company in the world, with over 115 million customers. (You will likely remember Heather from her pioneering work at Target, co-presenting with Ross Clanton from 2014-2015 and keynoting by herself in 2016).
    • Fernando Cornago (senior director, platform engineering) and Benjamin Grimm (senior director experience .com), Adidas: They will be presenting about the work they have done to elevate developer productivity at Adidas, including supporting the incredibly important e-commerce initiatives, as well as product design. They will share how they’ve educated top executives and even board members on critical technology concepts, and how they’re making all data easy consumable by everyone across the company.
    • Kira Barclay (director, analytics) and Elizabeth Conzo (analytics leader), John Deere: They will be presenting the amazing work they’ve been doing supporting both enterprise data initiatives, as well as incubating Horizon 3 initiatives and modernizing the software practices in some of the largest product lines at John Deere.
    • Ralf Waltram (VP of IT delivery), BMW: Ralf will be talking about the DevOps and Project to Product journey, which as he says, is how BMW is transitioning from project management to product management. In the BMW team’s words, this the “largest change to how business is done at BMW in twenty years.”
    • Jim Lloyd (chief of the innovation branch, field operations directorate) and Melinda Solomon (Agile training lead), USCIS: Jim and Melinda will be sharing the continuation of the DevOps journey at the US Citizenship and Immigration Services. Jim will be talking about specific mission objectives at USCIS, and the business and technology partnership.
    • Jaclyn Damiano (associate director) and Josh Stone (senior architect/evangelist), Verizon: Verizon has holistically undergone massive organizational and business changes in the past year. A voluntary separation package and outsourcing to third parties has changed the makeup of the team and the culture. A corporate reorganization so significant it is defined as “Verizon 2.0.” They will be talking about how to stay the course on digital transformation, cloud migration and culture change in such a turbulent environment.

    Continued Experience Reports

    This year, we will have six companies back to present their continuing experience reports at the conference. Having this pattern of repeat speakers may be a bit unusual, but I personally love that we’re following these courageous leaders along their journey. I want the experience to have front-row seats to an unfolding documentary of the ongoing transformations they are leading in their large, complex organizations.

    How has the story from the previous year evolved for the organization and the leader? What new obstacles emerged, and how did they overcome them? Is this a path the rest of us want to follow? What are the things worth celebrating as part of this journey and why? For DOES Las Vegas, we have the privilege of welcoming these people back to take the stage:

    • Scott Prugh, chief architect and VP software development at CSG: Scott has spoken at every DOES since the beginning. This year, I’ve asked Scott to speak on something he’s never directly spoken about, which is how they’ve overcome incredible architectural challenges as their transaction growth exploded.  This is one of the most incredible engineering achievements I’ve ever seen.

    Spanning the Business and Technology Divide

    One of the top challenges we see year after year is how to get business leadership on board—and by that, I mean enthusiastic and grateful business partners, who want to tell the world how all their goals and aspirations are finally achieved by working together with their technology counterparts.

    These are often the most difficult talks to find, because they require a technology leader with a great working relationship with their business counterpart, and visible success. In Las Vegas 2018, we had some fantastic talks along these lines (from Nike, Capital One, Target, The Walt Disney Company and Kaiser Permanente).

    This year, we’ll be featuring even more talks like this (33% more to be exact), showing how technology leaders are partnering with not just business leaders, but also other areas of the business, such as product leadership, security/privacy, legal, project management and so forth. Specifically, we are eager to hear from the CFO and Project Portfolio perspective. Here are a few talks I’m super excited to hear:

    • Chris O’Malley (CEO) and Joe Aho (CFO), Compuware: My fireside chat with Chris O’Malley last year was one of the most talked about sessions last year. I’ve invited him back with his CFO, asking them to teach us how to better interact with CFOs, a famously conservative group, and how we can win them over to help DevOps initiatives.
    • Levi Geinert (SVP and head of Agile technology experience) and Werner Loots (EVP consumer and business banking), U.S. Bank: Levi talk about his new role in the Experience Studios, where their goal is to reimagine banking, an effort being driven from the very highest levels of leadership. He and Werner will speak about some of their challenges and noteworthy successes, which has created excitement across the organization.

    Next Generation Operations

    After hearing ops needed more representation at DOES, in 2018 we reserved nearly a quarter of our talks to focus on ops and infrastructure challenges, and created a separate subcommittee to focus on this area. While we aren’t going to have as many next generation ops talks this year, it is our third largest talk track behind new experience reports and spanning the tech and business divide.

    What’s amazing is that we learned the elevation of this topic has fundamentally changed the feel of the conference itself. The programming committee has made an effort to help define and clarify what exactly the role of an ops leader is, and how all the technology and organizational changes there have been in how infrastructure is designed, delivered and operated. I’m thrilled to be able to see this presentation this year:

    • Scott Havens, director of software engineering at Walmart Labs and Jet.com: Until very recently, Scott was responsible for rebuilding the entire inventory management systems that support Walmart, the world’s largest company. He will be sharing how he used functional programming principles to massively simplify the vast architecture that supported the inventory management systems, making it simpler, more reliable, easier to maintain and cheaper to run.

    Subject Matter Expert Talks

    All leaders are, for the most part, self-teaching ourselves what we think we need to learn to be successful. Technology leaders in particular have to adapt to a somewhat constant rates of disruption and change happening around us. In the past, we’ve brought experts such as Dr. Christina Maslach (burnout) and Dr. Richard Cook (safety culture) to deliver talks about the domains we want to learn more about to help us reach our desired outcomes. This year we have the following subject matter experts onsite to deliver presentations:

    • Andre Martin, VP and chief learning officer at Google: Until recently, Dr. Martin was chief learning officer at Target, and before that, at NIKE. He will be sharing what his charter was in those roles, and why those organizations created his role in the first place, and how it could advance the mission of the DevOps Enterprise community.
    • Christopher Bergh, CEO and head chef at DataKitchen: He will be talking about the chronic problems of getting data from where it resides (typically trapped within data warehouses) to where it needs to go (by the teams who need data to make decisions, or manipulate it to make it more useful). Chris had a huge impact on the development of The Unicorn Project, and helped me see the parallel universe of DataOps.
    • Nicole Forsgren, head of DORA and Dr. Dustin Smith, human factors psychologist and senior user experience researcher at Google: They will be presenting all the amazing and continuing findings from the 2019 State of DevOps Report, which continues to uncover fascinating insights on what enables high performance.

    Networking Opportunities, Lean Coffee, Lightning Talks and More

    In addition to all the wonderful talk tracks and exciting presentations above, the conference program creates a forum for different ways to “get together and go faster.”

    I’ve said this before, but it is so important for the organizers of DOES to help attendees achieve their desired outcomes. One of the most special experiences at DOES comes from meaningful one-on-one interactions with your fellow attendees.

    To that end, and together with my friend and IT Revolution advisor, Jeff Gallimore, we have established different ways for people to learn, ask and answer as many questions as possible–based on experiments and what we learned from London earlier this year. Because the quality of the audience is one aspect that we think separates the DOES from all the rest, the more spontaneous conversations and interactions we can nurture onsite, the better for all.

    • DevOps Confessions: At the beginning of each day, programming committee members will read anonymized stories of confessions from leaders in the DevOps community to learn about the struggles, failures and near-misses. These are some of the best anecdotes you may ever hear.
    • Speakers Corner: We created a dedicated time and a location to ask the plenary speakers questions that go deeper on the information presented earlier that day.
    • Lean Coffee: Led by Dominica DeGrandis, author of Making Work Visible and the foremost expert in Kanban Flow within the IT industry today, attendees can connect with and learn from their peers in a semi-structured format all three days of the conference.
    • Birds of a Feather Sessions: This is more like the DevOpsDays unconference sessions, with less structure than a Lean Coffee format, and these sessions are driven by specific topics that attendees want to discuss and learn about. I thoroughly enjoyed the interactions of these sessions in Las Vegas last year.
    • Lightning Talks: These are rapid-fire, must-see presentations that happen from the main stage after the conference day has concluded. Also, as a bonus, the IT Revolution book signing happens immediately afterward.
    • Industry Party: In addition to sponsor giveaways, great food and drinks, this is when I’ll have the book signing of my newest title, The Unicorn Project. The industry party is one of my favorite times during the conference to continue conversations with my fellow attendees and speakers.
    • Slack Workspace: The conference will have a shared Slack workspace for people to interact with speakers, attendees and sponsors. In the past, this is where people have connected to make plans, search/recruit for job opportunities and more.

    As you can see, there’s a lot getting me excited for the conference this year, and I hope to see you there!

    To preview DOES Las Vegas 2019 and learn more about the conference, please watch previous videos of our presentations, download the past speakers’ slide decks and view photos from all past events.

    Special offer: Pre-order 10 copies (or more) of The Unicorn Project by Oct. 30 and receive $350+ off your next conference registration, plus lots of other bonuses. For more details click here.

    — Gene Kim

  • Common Cloud Security Mistakes and How to Avoid Them

    Common Cloud Security Mistakes and How to Avoid Them

    Over the last few years, it’s become apparent that traditional on-premise security policies are not a good fit for newer cloud-native environments. Even though the writing has been on the wall for a long time, the brewing security crisis still hasn’t been resolved. Far too many organizations continue to use security measures that are ineffective for cloud-native environments, along with inconsistent policy enforcement that leads to huge oversights and gaping organizational loopholes. The sad truth is that today, it doesn’t take a master hacker to infiltrate most cloud-native deployments.

    Many of the most infamous security breaches would have been extremely difficult to prevent even with an ideal security environment, but the weakness of the system is endemic, reaching far beyond a handful of vulnerable organizations. Even if some malicious actors could still get through, there’s no reason for organizations to leave their attack surface so blatantly unprotected.

    Here are increasingly common cloud security mistakes DevOps teams still make, and our suggestions for how you can stop them in your organization.

    Ignore Zombie Workloads

    Many organizations ignore zombie workloads that run on their architecture. When your team is stretched and you’re facing a number of serious security issues, it’s easy to dismiss zombie programs as nothing more than a harmless irritation.

    In actuality, having zombie resources scattered around your deployment blocks your ability to spot serious cryptojackers. Zombie workloads are often an indication of, and an invitation to, more significant invasions into your infrastructure. A report by SkyBoxSecurity revealed in 2018, cryptojacking was the leading attack vector. DevOps teams need to recognize the threat of hosting a program mining your resources for cryptocurrency, and take immediate steps to block them.

    Turn a Blind Eye to Leaky S3 Buckets

    AWS service buckets, particularly the S3 bucket, is one of the oldest cloud-native services. As a result, many S3 buckets are still governed by very old rules and regulations that leave many ways for someone to accidentally make the bucket public, open up access to unauthorized users and expose sensitive data.

    A study by HTTPCS reports 58% of AWS S3 buckets are accessible to the public, and 20% of them aren’t write-protected. Not only can malicious actors get to your sensitive customer data through S3 buckets, but often they can access your cloud credentials as well. Some of the most disastrous data breaches began from unrestricted access to S3 buckets, and it’s one of the most common causes of data breaches overall. It’s vital to regularly check your AWS console for public buckets.

    Allow Runtime Updates to Bypass the CI/CD Pipeline

    Every DevSecOps team agrees that your deployment is more secure when runtime updates are passed through the CI/CD pipeline, but that doesn’t mean the policy is always enforced. Developers will repeatedly ignore your security policies through practices, such as using open-source libraries, to avoid the security process of the CI/CD pipeline and speed up deployment.

    While this saves developers some time on releasing updates, it places a heavier burden on security teams, who have to run extra scans for these rogue workloads. What’s more, it builds complacency among DevOps teams, who assume there is no way to prevent unauthorized workloads and end up simply accepting them. Eventually, your security posture erodes to the extent that malicious actors can run harmful workloads without attracting your attention–until it’s too late.

    Permit Unrestricted Network Access

    Instead of spending hours on segmentation and separate access permissions, all too many DevOps teams fall back on a blanket set of network configurations that fall far short of the necessary access restrictions. They often place all their workloads into a single VPC, opening up access to third parties in the process.

    Without restrictions on public network access, it takes far longer for security teams to identify and isolate negligent and malicious activities. In a short space of time, DevSecOps teams find themselves overlooking serious oversights like unrestricted public root access, opening up enormous holes in their security profile.

    Faulty Rule Configurations for Micro-Segmentation

    When DevOps teams use micro-segmentation in containers, they face unique challenges. The more granular you get with your segmentation, the greater the risk you’ll miss faulty policy rules.

    Even your most familiar rule sets can create massive vulnerabilities. For example, if you allow your developers to use a specific IP to connect to the production runtime environment through SSH, you could unwittingly end up permitting unrestricted public access to sensitive areas. Sometimes, these faulty rule configurations go overlooked for as long as several months. To avoid supporting faulty rules, it’s important to audit them regularly with a tool such as Amazon Inspector’s Agentless Network Assessment.

    Avoiding AWS cloud security mistakes requires a shift in mindset. The harsh truth is a significant number of cloud-native deployments commit not just one, but several of the mistakes listed above. Cloud environments are deliberately decoupled from the network infrastructure in order to enable agile business practices, but DevSecOps teams continue to use network security techniques that aren’t capable of meeting the unique challenges of the cloud.

    The only way to fix these mistakes is to turn to new technologies designed for cloud security, such as using cloud workload identities to bridge the chasm between business logic and network infrastructure. Until ACLs and security groups are untethered from the network infrastructure and join cloud-agile business logic, they’ll fail to provide adequate cloud-native security.

    — Ran Ilany

  • The New Era of Kubernetes, With StackRox

    The New Era of Kubernetes, With StackRox

    Orchestrators are becoming the operating systems of cloud for the future. Which one do you think has become the dominant one? Ali Golshan, co-founder and CTO of StackRox, placed his bet on Kubernetes right from the start.

    StackRox is a Kubernetes-native security platform that helps DevOps and security teams operationalize security, providing richer context, native enforcement and continuous hardening.

    During this interview with MediaOps founder and editor in chief Alan Shimel, Ali discusses the adoption of Kubernetes and its prevalence today. More companies are realizing they can’t use traditional security. The tooling has to be native to the infrastructure they’re using, it must integrate into the build and the deployment. And Kubernetes is the best solution available, he said.

    Check out the interview below to learn more about microservices, containers and Kubernetes.

    — Veronica Haggar

  • Understanding and Implementing the APM Puzzle – Performance and Availability

    Understanding and Implementing the APM Puzzle – Performance and Availability

    While every organization is unique, there’s one universal goal everyone can get behind—creating and delivering an exceptional end-user experience. For both classic IT organizations and companies built in the age of cloud, delivering continuous availability and appropriate application performance is key.

    Although digital transformation has become a buzzword some would say is meaningless, the idea of digitizing a traditional company and building new businesses whose foundations are established upon the latest web technologies is critical in today’s IT and non-IT organizations. Think about the prevalence of cloud migration efforts during the past several years. Traditional organizations typically prioritize on-premises applications with increasing quantities of hybrid applications. But, because they aren’t yet fully transitioned to cloud—whether IaaS, PaaS or SaaS—their IT organizations need to live in both universes.

    Monitoring these environments at both the infrastructure and application tiers and across each stage in this transition requires support of a full stack of tools to cover web uptime, user experience, transaction monitoring, application tracing, log analysis and appropriate infrastructure monitoring. That said, modern organizations that have fully embraced cloud and leverage modern microservice architectures have similar challenges, but the exact same level of monitoring visibility requirement.

    Whether public, private, hybrid or multi-cloud, nearly every organization has moved to the cloud in some capacity. Regardless of what the company produces or the services IT provides, it must maintain uptime, availability and seamless performance to create and continuously deliver a user experience rivaling competitors and exceeding user expectations.

    Because let’s face it, even though every business is different and virtually every market is saturated, consumers and B2B companies have more options than ever. Without delivering a solid end-user experience, there’s an ever-increasing plethora of alternative vendors and providers from which customers can choose.

    Public Cloud Platforms for Classic IT Organizations and the Cloud Generation

    Let’s explore a few differences between how traditional IT organizations and cloud-era companies interact with the cloud. At a high level, Azure is a natural choice for IT companies with significant investments in apps traditionally acquired (not built) by the company and managed by their IT team, that are now tasked with digitizing their business by leveraging public cloud platforms. These types of companies often have Microsoft Office, Microsoft Exchange and other Microsoft products already implemented on-premises, and Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS) solutions as well. If they’re now adding a public cloud platform to their mix, staff expertise and solution familiarity make adopting Microsoft Azure a natural next step. Microsoft has long recognized the need to make these types of transitions and mixtures easier, demonstrated by its Office365 suite (as an example).

    On the flip side, companies that were born fully in the cloud, (i.e., relatively newer organizations without a legacy anything on-premises, with respect to IT infrastructure) will likely have a higher propensity to choose a provider such as AWS or Google Cloud even though Microsoft, Oracle and others are certainly competing there as well. So, it’s not a matter of one being intrinsically better or more fully-featured, but about which is the best fit for the organization and its priorities.

    At the end of the day, however—regardless of organization type or public cloud platform implemented—every company needs monitoring tools and solutions that keep applications up, running and performing seamlessly. With an integrated set of simple, easy-to-use, quick to value and powerful solutions, organizations can achieve truly proactive lifecycle assurance of application availability and performance.

    Uptime and Seamless Performance: Putting Together the APM Puzzle Using All the Pieces

    Each and every piece of the APM puzzle must be incorporated to achieve full-stack visibility and ultimately top performance: user experience, metrics, traces and logs. Having a log management solution monitoring availability, enables proactivity and enables IT to react quickly to help identify and remediate problems is paramount—it’s table stakes that everything be available. After all, if a website or page isn’t accessible, business transactions cannot be processed and that business is effectively down.

    Creating and maintaining a healthy application involves not only ensuring it’s functionally available to users; it must also be performing appropriately—continuously delivering both a reasonably responsive user experience and supporting the required volume of transactional work. This means a complete view into all aspects of performance—from the website and webpages all the way into and across all relevant application components and their associated infrastructure—be proactively visible and monitored.

    There is thus a natural and increasingly urgent workflow affinity between logs and APM—across the development lifecycle. When errors occur, it’s critical to understand, precisely and immediately, where are the impacts on service performance, or if there even are any impacts. Conversely, when application performance issues arise, it’s critical to immediately know exactly which errors—across the complex and constantly changing infrastructure and application stack—are directly related to the problem at hand.

    Without this bi-directional workflow integration, not only can application performance and availability not be managed proactively, but any issues with application service availability and performance will take far longer to diagnose and repair—seriously impacting the business bottom line.

    Just because everything is available doesn’t necessarily mean it’s appropriately performing for the end user trying to use the application.

    With all this in mind, it’s paramount to implement powerful, easy-to-use solutions that’ll achieve integrated application performance and availability management for any type of organization operating on-premises and/or cloud-based applications across all cloud environments.

    Conclusion

    While traditional IT organizations and cloud-only companies are different in many ways, providing exceptional end-user experience and achieving seamless availability and performance (no matter what) is a common and increasingly critical business goal. To achieve business success, organizations should choose a complete suite of simple, powerful and integrated solutions to optimize and manage their cloud-hosted applications and platforms. Anything less leaves the APM puzzle unsolved.

    — David Wagner

  • The Real-Time Innovation Dividend

    The Real-Time Innovation Dividend

    Time is compressing. The attention span of individuals and organizations is becoming ever shorter. There are only brief windows that can be devoted to any given transaction.

    Expectations around situational knowledge, updated in real-time, are compounding. Customers expect the applications they interact with know where they are, what they are looking for and what their preferences are in terms of price, value, design and timeliness of delivery. If the proper options aren’t provided immediately, the customer will move on to another provider.

    While the time available to an algorithm or application is contracting, the complexity of the tasks for successful interactions is increasing. Digital businesses must do more in ever shorter time windows. Differentiation in the digital world has a lot to do with a deep understanding of the customer based on multiple data streams and driving decisions that provide a deeply personalized experience.

    In business, we need to have a current picture of our situation. We build models and analytic dashboards, but these fall short in allowing us a real-time view. The latency of these models may be measured in seconds, minutes, hours, even days and weeks. As latency expands, the picture is not of the moment and that difference defines operating risk. The phrase “time is money” has never been more accurate.

    Brokerages require as close to a real-time view of positions allowing them to manage risk more closely, in terms of their aggregate position, based on a transactionally correct view of precisely what they have on their books to respond in real-time to global market changes.

    For retailers, it means knowing the content a customer has seen and the environment where they encountered it. Did they just come from a brick and mortar store? What digital journeys have they been on? What online content have they been perusing? Continually adaptive models use the answers to these questions to select active customers and recommend options that address what they are searching for.

    The digital shopping experience is composed of multiple linked processes, working in concert to continually understand the customer experience. Different system elements–user profiles, decisioning, recommendation engines and machine learning and AI–require data across different time windows. Some of these systems deal with terabytes of data and some petabytes. Some require absolute consistency and for some eventual consistency is good enough. In many of these systems, there is a demand for hyperscale within tight time windows.

    The ability to take in more data within a given time window feeds the currency of the context. It is not enough to have a lot of data, but you also need the most current view of that data. Operating at hyperscale enables an organization to deliver exponentially more data than traditional databases. This makes models more accurate and, by extension, more valuable.

    Scale Plus Speed Equals More Time

    In some sense the combination of scale with speed creates time, giving you the ability to do more within a given time window. Consider this a dividend, allowing the use of more data or allowing the process to be completed in less time.

    The systems that interact directly with either customers, employees or clients are edge computing systems, pulling in and processing data within relatively tight time windows. Edge systems may have expiry windows where data is deleted after a given time window where it is deemed to be stale.

    The data collected and processed at the edge may be moved to a system of record or core transactional store and kept for longer periods providing historical context. These data sets may grow to petabytes in size while still needing to support response times measured in milliseconds. Meeting these requirements requires hyperscale capability, where the performance of data access does not degrade as the repository of information grows.

    Here’s a real-life example. We must match the information collected regarding devices, identity and patterns that establish context against our database of user profiles. We want to run more sophisticated recommendation engines based on these patterns to ensure we are putting the closest thing to what the customer wants in front of them. We also want to make pricing decisions in real-time, to gain the largest basket at the best margins. We may have established a model that tells us customers with this profile are likely to make additional purchases after this transaction, so our analysis and optimization boundaries go beyond just this transaction. We will want to log this so we can track this behavior to validate the model. We have these processes going on, some in parallel, others in sequence:

    • Establish an identity profile of the customer.
    • Match that profile against a database of profiles that models likely desires and behaviors.
    • Based on that match, determine the products and/or services to recommend.
    • Select the content and media types based on the user profile.
    • Determine pricing based on the user profile and the transaction profile.

    The last element, real-time pricing, is something we want to modify to take into account the margin and profitability of the customer over time. We also know that if this impacts the overall window of the transaction the customer has a higher likelihood of abandoning the transaction and we can lose out on not just this transaction, but a whole set subsequent to this one.

    Doing Better for Both the Customer and the Business

    By building models based on hyperscale capability, 10 milliseconds are saved here, another 20 milliseconds there. This creates the time bandwidth in the overall process to add the notion of optimizing pricing around not just this transaction, but the value of this transaction profile and the relative margins of the various components in this sale and other subsequent sales that are likely to happen. We have created time to do this additional processing and do better–better for our customers and better for our business. And we know that as we add more data points to our profiles and scale up to include more data overall, we won’t experience performance degradation. These time benefits will remain. This is the real-time innovation dividend.

    — Lenley Hensarling

  • Continuous Optimization: An Idea Whose Time Has Come?

    Continuous Optimization: An Idea Whose Time Has Come?

    Agile makes development deliver code faster. CI makes testing move faster and CD makes delivery faster, but what keeps track of the volume of change all of this introduces and delivers optimizations faster?

    That is the question Opsani wants you to be asking. And it’s a valid question. Optimization in a complex and constantly changing software world becomes more important–if it can keep up. Opsani thinks it can, with a little AIOps to help anyway.

    The premise is simple. There are ways to adjust the environment that might increase performance and/or reduce costs. Those ways are individually relatively simple (such as JVM settings or cloud instance sizing), but combined they make a complex web that impacts performance as a whole, with individual bits sometimes helping and sometimes hurting.

    Up JVM memory on a large instance and it might help. Switch to a smaller instance later, and that JVM change may cause problems on the smaller footprint, for example. So something more dynamic is needed. As code changes, best optimization options might change also. As the other parts of the environment change, that magnifies the concern that applications are not running at their best and might be costing too much money.

    Opsani’s answer to this problem is continuous optimization. Using AIOps to check different combinations of settings at a rate that operations staff couldn’t manage even if they did have the time. And they generally don’t.

    From my (not their) perspective, there are two pieces to this puzzle. First is gathering inputs and determining performance, second is tweaking settings. Then repeat. Seems simple but the environment continuous optimization would work in is increasingly complex. Any look at how many places optimization can occur in a given environment–from VM/Instance to code to network to management platform to storage/database choices–there is a lot going on, and all of these settings can impact each other.

    Hence the idea of continuous optimization appeals to me. They’ve got the interfaces that one would expect to gather inputs, names such as Jenkins, DataDog and New Relic. They’ve got the interfaces to enact and test out changes too, with interfaces to products such as Kubernetes, Terraform, Rancher and Wavefront. So it certainly appears they’ve got the basics covered. Of course there are vendor interfaces I’d like to see that aren’t in the list of integrations, and no doubt the same is true for you. But the core is here, getting to the monitoring and management tools most companies use regularly.

    Opsani seems to be aware of the different comfort levels of various organizations, also. Able to run in dev or test as well as production. Since every organization has a different taste for putting new ideas into production, this is a good idea, though personally I would aim for eventual production rollout, just because that is where the rubber meets the road. Having it running as part of normal operations means even that small change that reduces responsiveness of your application by 25% (we’ve all seen it) will be detected, and Opsani can try changing some of the environment to compensate.

    When I spoke with them, we did not discuss cost, but we did discuss savings. For budget-sensitive environments, it is worth looking into the cost in your organization versus the potential savings in actual monthly dollars. Here is a screenshot showing the cost measure combined with the performance measure. Reducing monthly overhead to pay for a tool that also improves performance might just be a no-brainer–if it suits your environment.

    I can’t say if it suits your environment, nor can any other analyst/pundit. That’s for your organization to decide. But the idea of continuous optimization is a good one. Opsani is not alone in working on this problem, so even if this particular tool doesn’t suit your needs, you can look for others that do. I recommend getting the demo and seeing what they’ve got, and how it might help in your environment.

    — Don Macvittie