devopsy.kinsta.cloud

Category: Blogs

  • How Does That Stack Up?

    How Does That Stack Up?

    There’s an entire class of successful innovations made up of things that people didn’t realize they needed. Things that were an obstacle they found a way around and didn’t think about until the innovation showed them an easier way. Think of things like virtualization (hardware was the bottleneck, but “That’s just the way it is,” until it wasn’t) or web monster shopping sites (“They don’t have that in the stores; I guess I’ll live without,” until you could order the weirdest or smallest things from the likes of eBay and Amazon).

    My rule here is that I only talk about products and services if I use them and find value in them. And even then, I try to do it sparingly. But in the spirit of the innovation story you just read, I’m going to point you at one of the coolest new websites on the net. I don’t know the company; have not done business with them, couldn’t even name a principal. But I have spent a surprising amount of time on their site, both in the Feed section and Browsing Stacks.

    The site is Stackshare.io, and the reason I think it is so innovative is what and who it is aimed at: Listing companies’ DevOps stack and offering advice on different parts of the DevOps stack.

    The Browse Stacks section is for presenting what other organizations are doing, so you can get good ideas for your own stack. But the developers of the site appear to have recognized the other useful aspect of this information: Matching organizations to prospective employees based on technologies. You can go look and see that Company X is using GitLab, for example, and that can then influence your job search.

    The Feed section is just a running discussion that uses categories to ask questions or offer insight and advice about decisions a given organization came to—so, “Chose X over Y” is actually a standard subheading for posts, as is “Need advice on Z” or “Recommends A”. It makes for great reading, and no doubt while reading through, you’ll have some advice to offer one of the “Looking for advice” posts.

    The Stackshare.io participants seem to range in size from startup to massive, and that is one of the things I hope they change as they grow—the options for looking at DevOps stacks are “Popular” and “Trending”. We all want more filters than that—organization size, number of apps, stuff like that—to help us zero in on environments that are similar to our own. My little company does not have the needs that Facebook does. And while it’s true that some startups use more tools in their toolchain than Facebook, you get the idea.

    Another issue I had with Stackshare.io’s site (that I fully understand, but still wish could be different) is forced registration/login to see some data. It’s not even particularly sensitive data—I know what ELK and Azure Data Services are, so putting the definition/description behind a registration page/login is kind of silly. But every free site needs data to pay the bills, and I suppose I’m glad it is info that’s also available elsewhere that is behind a reg wall.

    The company offers APIs for integration to your site/tool and private company instances of StackShare to help you manage one of my other gripes—the five (or fifty!) different DevOps stacks many organizations have allowed to develop in-house.

    So if you are job hunting, Stackshare.io can help you find companies doing what you would like to do or know you’re good at. If you are an organization trying to improve or set up a new toolchain (which is how I found the site), it has a lot of information to digest, though not all of it is easily accessible at this point. Either way, keep kicking it and keep an eye out for tools that do the job, no matter where you are looking.

  • Labor Day 2021

    Labor Day 2021

  • Progress Expands Chef Automation Portfolio

    Progress Expands Chef Automation Portfolio

    In advance of its ChefCon 2021 conference, Progress today unveiled a series of enhancements to its Progress Chef automation platform that includes managed services and a software-as-a-service (SaaS) edition of its offerings as well as tighter integration with cloud services and other third-party tools.

    Sudhir Reddy, vice president of engineering for the Chef business at Progress, said the SaaS platform, now available in beta, combined with the managed services provided by Progress will make the automation platform much more accessible to a wider range of organizations.

    Progress is now also extending the reach of its Chef Compliance Automation for Cloud Resources offering across Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) to include Chef premium content that aligns with best practices for each cloud environment in addition to providing integration with Azure Policy, a suite of tools from Microsoft that compares resources to a set of business rules that define how cloud infrastructure should be employed.

    Chef

    Finally, Progress has enhanced Chef Enterprise Automation Stack to provide tighter integration between compliance and infrastructure automation along with adding infrastructure operations dashboard, support for Windows patch management, integration with third-party secrets management tools, and improvements to Chef Workstation and Chef Test Kitchen to simplify testing within application development processes.

    With the release of a SaaS platform and the availability of managed services, Chef is joining a long list of IT vendors that are removing responsibility for deploying and securing their platforms from internal IT operations teams. It’s clear more organizations now want to spend more time on building and deploying software than managing the platforms that automate those tasks on their behalf, said Reddy.

    It’s not clear how many IT teams that have already deployed a platform might shift over to a SaaS platform or rely on an IT vendor to manage that platform on their behalf. However, in the wake of the COVID-19 pandemic, many IT teams continue to work from home to help combat the spread of the virus. Many of those organizations have either shifted platforms to the cloud themselves, adopted SaaS platforms or outsourced the management of IT platforms altogether. There are also many small organizations that simply don’t have the internal expertise and resources required to stand up an IT automation platform on their own.

    That approach also makes it simpler to converge security, compliance and IT operations management within the context of a larger DevSecOps workflow, noted Reddy.

    The great paradox of IT automation has always been the level of expertise required to achieve it. Organizations that lack the expertise required to create automated playbooks, for example, don’t derive much value from an IT automation platform. It’s only been larger companies that have mostly derived the most benefit from investments in IT automation. However, as IT automation becomes more accessible via SaaS platforms and managed services, the level of expertise required to benefit from it naturally drops. In fact, with the advent of artificial intelligence (AI) for IT operations (AIOps), many manual IT tasks are increasingly being automated.

    It’s too early to say whether the IT industry as a whole is on the cusp of the next wave of automation, but the raw ingredients that make up the primordial soup needed to achieve that goal is, at this point, only awaiting a catalyst.

  • DevOps World 2021: FinServ, Leadership, Practitioner and Government Tracks

    DevOps World 2021: FinServ, Leadership, Practitioner and Government Tracks

    What does it take to power a successful DevOps conference? For DevOps World 2021, it all starts with the ‘engine’—the content. This year’s event, hosted September 28-30, brings more than 100 sessions divided into a number of tracks designed to teach, inspire and guide the DevOps industry to the future. The diverse lineup includes financial services, leadership, practitioner and government tracks.

    New this year are the federal and financial services tracks. The sessions in these tracks will be led by enterprise and government agencies including Capital One, U.S. Air Force, The Internal Revenue Service and more. Attendees will come away from these sessions with unique and actionable advice tailored to these industry segments to help them keep up with the rapid pace of digital growth and transformation today.

    This year’s DevOps World tracks are designed to give a comprehensive look at DevOps applications, challenges and successes across industries and verticals. With over 130 speakers from around the world, attendees will gather virtually to share insights, helping to drive the future of software delivery, together.

    Here are a few highlights from these tracks at DevOps World 2021.

    Financial Services Track

    Despite heavy and increasing regulatory pressures, banks and financial services organizations from all over the world are proving that speed does not jeopardize compliance and flexibility does not come at the cost of repeatability. Some of the best-known banks in the world will share key pillars for success, what enterprise-class release pipelines really look like, how to optimize, measure and share success—even how to dissolve your central IT organization. This track will take a deep dive into the lessons learned along the way and best practices for implementation.

    Sessions such as “Enterprise Release Pipelines For The Financial Industry,” and “Salesforce and Automation: FinServ And The Non-Technical User,” will guide attendees through the use of DevOps in the financial sector.

    Leadership Track

    Leaders aren’t born with their skills fully formed—they’re made. They mature into their positions over time, growing stronger with training and experience gained along the way. This new track, chaired by independent analyst firm Accelerated Strategies Group (ASG), is designed to provide attendees access to strategic business thinking and deep technical expertise. The mix of presentations, panels, hands-on exercises and peer interaction will equip a whole new generation of digital leaders. Each unique session will provide attendees with valuable strategies they can take back and apply to their practices. Above all, this track will help leaders to differentiate their business and drive strong transformation initiatives.

    Sessions such as, “A Hundred Deploys A Day: Five Steps To Success,” and “When You Exclude, You Lose: The Hidden Costs Of Exclusion,” will help to kick off this learning opportunity for leaders. For those interested in finding out how to “Put Customers At The Center Of Software Delivery Management,” Forrester analyst Margo Visitacion has a session covering how leading companies are implementing this new, customer-centric operating model.

    Practitioner Track

    Amidst a year heavy with data breaches, leaks and hacks, security continues to be top of mind for software leaders and practitioners. From the software being delivered to the pipelines that deliver them, identifying potential attack vectors is more important than ever; not to mention the challenges of achieving and retaining compliance in a rapidly changing landscape.

    This year’s practitioner track was created to focus on practical security topics. Attendees can benefit from sessions outlining threat modeling, common failures and how to avoid them and the roles of observability and culture in security. Attendees will learn about hot topics including software bill of materials (SBOM) and military-grade container security. Sessions such as “Securing The Software Supply Chain – It’s Not Just About The Code,” for example, offer expert insight for practitioners in the DevOps space.

    Federal Track

    DevSecOps has hit its stride in the federal space. Few systems are as critical as those in the public sector, and ensuring efficiency, security and compliance across the table has been a major focus. DevSecOps is playing an important role for government services and agencies as they work to meet the needs of both private citizens, the public sector and the military. Speakers in this track will share exactly how this can be accomplished.

    Sessions will cover how federal agencies are implementing DevSecOps processes to automate and secure their software supply chains. An important part of this conversation will include how these implementations help to deliver higher quality services to citizens as well as provide more capabilities to our military. Sessions such as “From Startup To Enterprise: Migrating The Air Force’s Largest Data Center To Cloud Computing And DevSecOps,” will deliver an inside look into the latest federal advancements in DevOps and DevSecOps.

    Free registration is open for the DevOps World 2021 — take advantage of these comprehensive tracks and start the journey to the future of software delivery by registering today!

  • The Next Phase of Pandemic Tech Transformation

    The Next Phase of Pandemic Tech Transformation

    Last spring, we were inundated with headlines, tweets and Medium posts applauding the rapid digital transformation that businesses were going through—almost overnight—due to the pandemic and the shift to remote work. It made for an interesting feel-good narrative at the time, but it didn’t paint the full picture. Companies were thrown into the deep end; many barely staying afloat by implementing quick-fix, surface-level changes that they assumed would only be needed for a short time. Turns out, the “transformation” touted was just the tip of the iceberg.

    More than a year later, the workforce is still in flux. The reality is, some form of distributed, hybrid work is likely here to stay. Employees will continue to expect remote options and customers will want seamless, digital ways to interact with businesses, pandemic or not.

    As a result, companies must move past the temporary, band-aid solutions of last year and make those sweeping changes permanent. It’s time to move forward with true, sustainable change: Technical, experiential and, most importantly, cultural. Every company will need to become a modern technology company capable of delivering first-class digital solutions to customers, partners and employees—or risk becoming obsolete.

    Transactional Vs. Transformational Change

    The good news is just about every company understands the value of leveraging technology. A recent 2021 State of the CIO survey found that 82% of CIOs said they implemented new technologies, new IT strategies and/or new methodologies over the past year. The issue is how companies go about their technology deployments.

    People talk about digital transformation all the time, but it’s been used so much that it has become an unhelpful misnomer. More often than not, the change that companies are implementing isn’t truly transformational, but rather transactional or just slightly incremental.

    When companies have a transactional mindset, the focus is on immediate, simple and predictable changes. The purpose—or, more importantly, the outcome—is simply to continue business-as-usual. This is reminiscent of many companies last year turning to technology just to keep the lights on. A transformational mindset, on the other hand, aims to disrupt this business-as-usual and fundamentally change the paradigm in how the company operates through ways of working, use of technology and culture. It’s purposeful, aiming to solve business problems holistically and spur long-term growth.

    To be successful in today’s climate and to gain a competitive edge with customers, companies must strive to be transformation-focused.

    How to Move Toward True Transformation

    Here are three examples of how companies can shift from a transactional mindset to a transformational mindset.

    Cloud Migration vs. Modernization

    Often, when companies talk about their use of cloud, they tout that they’ve “moved to the cloud.” But all too often, it’s treated as a one-time event; a destination to reach and a box to check. At the outset of the pandemic, we saw so many organizations quickly mobilize to shore up their digital strategies and ensure they were thinking about the limitations of doing business in a virtual context, but their cloud strategies didn’t evolve to rethink these paradigms, as well. They simply accelerated their migration strategies to get out of their physical data centers and into the cloud.

    The opportunity to leverage the cloud is so much bigger than that. It can unlock greater efficiency, flexibility and growth and underpin new digital experiences and revenue opportunities—exactly the kind of strategies most companies envision. For example, health care leader InnoCare was struggling with outdated clinic management software. Instead of just moving the old bits to their cloud provider, they adopted a broader digital strategy to modernize their delivery capabilities and reimagine both the patient and clinician experience, setting new industry standards in the process. This is what we refer to as modernization and it is what leads to transformation.

    Software Engineering vs. Product Engineering

    With the rapid growth of software, it’s no surprise that software engineers are in high demand. The U.S. Bureau of Labor Statistics projects that software engineering job openings will grow 22% through 2029. And while software engineers will play an irreplaceable role in helping build innovative solutions, transformational-focused companies know to bring more people under the tent. By combining software engineers with other cross-functional experts who bring a different level of artistry, design and audience understanding, the end result is a more engaging, customer-centric product that evolves and grows over the entirety of its useful lifespan.

    This is exactly what fitness giant Nautilus did. They brought together a team of engineers, data scientists and machine learning experts to help bridge the gap between their equipment manufacturing prowess and their digital experience and software development goals. Collectively, they produced a total platform that integrated hardware, software and data to create a dynamic workout regimen that impressed users and fended off competitors.

    Moving Beyond Proof-of-Concept to Long-Term ROI

    A proof-of-concept (POC) is a rite of passage in the tech world. It’s how a company or team demonstrates that their idea is feasible and can work in a real-world application. But POCs alone are insufficient; they are transaction-minded and don’t focus on achieving lasting business outcomes or generating deeper ROI. Rather, they mostly focus on technical feasibility. The key to upleveling toward transformation is by focusing on the processes, not just the end product. When testing features in a real-world setting, make sure that you’re proactively measuring not just that they work—but that they contribute to business imperatives, meet customer expectations and strategic outcomes. And if they don’t, go back to the drawing board and optimize with those higher-level goals in mind.

    Culture is Key

    As you can see, the difference between a transactional and transformational mindset is more about culture than technology. A culture of innovation and modern ways of working leads to transformation that fundamentally shifts the way technology is conceptualized and created. It isn’t solely about gaining efficiencies or cutting costs—instead, the focus is on making the lives of customers, employees and everyday users better. Transformation-focused companies believe in the promise of technology advancements, but they believe that it also can make operations smoother, customer relationships more meaningful and increase revenue when implemented with the right combination of skills, disciplines and organizational buy-in over time. It’s those companies who will thrive in this new era.

  • SRE’s Guide to Pragmatic Incident Response

    SRE’s Guide to Pragmatic Incident Response

    In my past experience as an SRE, I learned some valuable lessons about how to respond to and learn from incidents. If you want the TL;DR, I’ll summarize them here:

    • Declare and run retros for the small incidents. It’s less stressful, and action items become much more actionable.
    • Decrease the time it takes to analyze an incident. You’ll remember more, and will learn more from the incident.
    • Alert on pain felt by people – not machines. The only reason we declare incidents at all is because of the people on the other side of those machines.

    Now, let’s dive into each of these lessons a little deeper, and explore how they can help you build a better system for pragmatic incident response.

    1. Focus on the Small Incidents First

    The bad habit of ignoring small issues often leads to bigger issues. You should run retrospectives for small incidents (slowdowns, minor bugs, etc.) because these often have the most actionable takeaways—instead of shooting the moon and creating “rearchitect async pipeline” as a Jira ticket that never happens. Focusing on low-stakes incidents and retrospectives are a great introduction to behavior change across your organization.

    Let’s look at an obvious example of how a focus on small incidents can have an outsized impact. Case in point—my apartment. I live in an old candy factory retrofitted into apartment units. We have an elevator (thank God), but some of the buttons don’t light up when you press them. The LED display doesn’t match up with the numbers on the floor buttons. Yes, the elevator goes up and down, but overall, you can tell that things are wrong with it.

    One day, I came home and noticed an “Out of Order” notice on the elevator door. Was I surprised? Not at all. Of course an elevator with mislabeled buttons and broken LEDs would stop working!

    This isn’t dissimilar from an important software lesson—ignoring small issues often leads to much bigger issues. What starts as an inconvenience can lead to a complete breakdown. This is why you should focus on the small incidents first. I hear a lot of companies say, “We need to fix incident response! Every time we have an incident, it’s just chaos!”

    They are talking about unexpected downtime during a high severity level incident and they want to improve it.

    I say that’s the wrong type of incident to use to fix your incident response system and process. Focus on the small incidents first. Running retros for small incidents can help you build strong incident response models, because they have the most actionable takeaways and they are the best way to change behavior through repetition and practice.

    If you have a high-stakes, 12-hour incident and you run a one-hour retrospective you’re not going to get the results you want. You need to start small. Run retros for bugs that were introduced; maybe a bad data migration that didn’t really impact anything but took up a couple of hours of your day.

    Heidi Waterhouse captured this idea really well in this piece on reliability. Every airplane you’ve ever flown on has many tiny problems, Waterhouse said, “… like a sticky luggage latch or a broken seat or a frayed seatbelt. None of these problems alone are cause to ground the plane. However, if enough small problems compound, the plane may no longer meet the requirements for passenger airworthiness and the airline will ground it. A plane with many malfunctioning call buttons may also be poorly maintained in other ways, like faulty checking for turbine blade microfractures or landing gear behavior.”

    I couldn’t agree more. Extrapolating to software: The small things are typically indicators of bigger issues and could cause catastrophes down the road.

    2. Track Mean Time to Retro (MTTR)

    It’s important to think about what you measure in your organization. You should be measuring how you’re improving, and the most important metric here is mean time to retro (MTTR). Everyone should be tracking MTTR. It’s a great statistic to improve incident response in your team because it helps you understand the delay between incidents and retrospectives.

    The easiest way to have a bad incident retro is to wait two weeks. It’s better to get into a room quickly and hash out what happened than wait a long time until you’ve got everything perfectly prepared.

    Tracking MTTR can help you hold prompt and consistent retrospectives after incidents. Set a timer and make an SLO or SLA for yourself that says, “This is how long we take for retros.”

    Retro time will vary depending on the severity of the incident itself. If it’s a SEV1, clear everyone’s schedules, because you need to have retro within 24 hours of the incident. For SEV3 incidents, you have much more leniency.

    I also like tracking the ratio of retros to declared incidents. This is a metric that should go up; you should see your ratio of retrospectives to incidents increasing. You can break down that number by severity, as well. If you have a low retro ratio for a SEV1 versus a SEV3 incident, that might be okay at first (remember, start small) but you want those metrics to eventually become equal.

    3. Alert on Degraded Experience with the Service, and Not Much Else

    The severity of incidents is directly linked to customer pain. We would not declare SEV1s if there weren’t a lot of people feeling a lot of pain.

    Alerting on computer vitals is an easy way to create alert fatigue and burnout. As your company starts to scale, you are going to use more CPU; you’re going to use more memory. Tying alerts to computer vitals is not a good sign.

    If I run, my heart will beat faster—it’s just doing its job. Paging people at 2:00 a.m. because disc capacity is at 80% even though you won’t run out of space until next month is a good way to lose great teammates. I have worked with people who left their previous companies strictly because they got paged too many times for stuff that didn’t matter.

    This is why you need to alert on a degraded experience with the service and not much else. A CPU burning hot at 90% is not necessarily a bad thing, but you need context to decide. Create SLOs that are tied to customer experience and alert on those. People experiencing problems with the service is the only thing you should alert on—for the most part.

    One of the best ways I’ve seen to think about this came from Soundcloud developers, who explained that you should alert on symptoms, not causes. My fast heartbeat is not necessarily a problem. But if my elevated heart rate leads to lightheadedness and I fall—that’s a problem. So, I need to be able to alert on something like that. Paging people at 2:00 a.m. because disc capacity is at 80% and you won’t run out until next month is not good. But paging people because you know that disc capacity problems cascade into other, systemic problems is. You can apply the same thought to other potential causes of an outage. Paging alerts that wake you up in the night should only be based on symptoms.

  • How to Improve Cloud Management

    How to Improve Cloud Management

    Cloud technology underpins emerging technologies like artificial intelligence (AI), IoT, edge computing and containerization. Organizations must prioritize implementing effective cloud management practices to avoid spiraling costs and potential security and compliance violations.

    The COVID-19 pandemic has vastly accelerated cloud adoption. To support remote work, many businesses have moved workloads from on-premises servers to the public cloud. At the same time, thanks to the proliferation of technologies like AI and machine learning, organizations are generating more data than ever, much of which is also being stored in the cloud. It’s no surprise then, that the explosion in demand for cloud services is showing no sign of slowing down. Gartner predicts that worldwide end-user spending on public cloud services is forecast to grow by 23.1% in 2021 to total $332.3 billion.

    But, it’s not all smooth sailing. As the average organization’s cloud infrastructure grows in complexity and size, it becomes increasingly difficult for teams to manage it effectively. This has significant security, compliance and cost implications. According to Accenture, an astronomical 30% of organizations’ cloud spend is currently wasted.

    So, what can you do to ensure you avoid the most common cloud management pitfalls?

    See the Big Picture

    It’s surprising just how little visibility many businesses—even those with large teams of cloud architects—have into their cloud infrastructure. For instance, one recent survey found that over 25% of IT departments have no idea what their monthly cloud spend actually is.

    Before taking steps to optimize your cloud management practices, it’s crucial that you gain full visibility into your current situation. You need to understand your cost history, audit trail and CPU utilization patterns to identify where you’re overspending.

    Plus, make sure you’re using tagging consistently. A well-defined organization-wide tagging policy is essential, enabling you to accurately visualize expenditure by category. It’s also good practice to set up alerts which are triggered when a user launches instances without tags. This prevents any potential oversights.

    Develop a Change Management Process

    Gone are the days of rigid change management processes handled solely by IT teams. Nowadays, business units can acquire cloud services without even involving IT.

    In the cloud, change management is a series of continuous integrations, deliveries and deployments. Given this fast-moving environment, it’s crucial to implement a robust change management process or risk spiraling costs and potential compliance violations.

    It’s important that your change management process gives you visibility into and control of each infrastructure change without compromising on delivery speed. To achieve this while establishing strong policies and rules, it’s worth considering automation for at least part of the application delivery process. By auto-approving all routine and low-risk changes, you can free up time for your developers to focus on more complex projects.

    In addition, it’s worth integrating your change management process with your DevOps tool stack. You can use collaboration tools like Slack, Teams and/or Jira to ensure everyone has visibility into changes and resolve any issues quickly.

    Continuously Optimize your Cloud Infrastructure

    Unfortunately, when it comes to effective cloud management, your work is never truly done. Conducting a one-off review of your existing cloud infrastructure will only get you so far.

    Many businesses make this mistake and find themselves falling back into their old bad habits a few months down the line. To keep your cloud infrastructure in check, it’s best to continuously track a whole host of factors, including costs, changes, users, permissions and compliance breaches. After all, it’s much easier to solve an issue when you are able to spot it before it gets out of control.

    Now you have an idea of where to start when it comes to improving your cloud management practices. However, manually juggling all of the above considerations is a significant undertaking. It’s prohibitively time-consuming for many organizations whose DevOps teams are already overstretched. This is why a whole host of SaaS-based cloud management tools have sprung up in recent years. These offer unparalleled visibility into changes, resource utilization, costs, security, compliance, performance and more. Yes, they come at a cost. But, most businesses find that the savings such tools enable them to identify significantly exceed any outlays.

  • The Key Benefits of Observability for SREs

    The Key Benefits of Observability for SREs

    In today’s technology landscape, organizations strive to champion innovative ideas, techniques and technologies to achieve success and outshine their competitors. For this reason, site reliability engineering (SRE) has become one of the fastest-growing enterprise roles and a set of organizational practices for fast and reliable software delivery. 

    SREs use various tools and practices at their disposal to manage services at scale, such as observability. Observability is the ability to infer a system’s internal state(s). It provides actionable insights into when errors occur within a system and, more importantly, why they occur. For SREs, this actionable data can be important to providing secure and reliable applications. 

    To gain more insights into the benefits of observability for SREs, I asked SKILup Day participants and DevOps Institute Ambassadors to weigh in. Here’s what they shared: 

    Sponsor, Priya Satheesh, CEO, Instana 

    “As their name implies, site reliability engineers are tasked with keeping the applications, architectures and websites up and available. Observability solutions put alerts in front of them at the first indications of trouble, with proper context and information so they can take action before issues become incidents and start affecting their customers. In addition, AIOps and machine learning help them to predict events and standardize responses for common occurrences to reduce response and repair times.”

    Helen Beal, chief ambassador, DevOps Institute 

    “Embracing observability supports SREs’ goals by:

    • Reducing the toil associated with incident management—particularly around cause analysis—improving uptime and MTTR.
    • Providing a platform for inspecting and adapting according to SLOs and ultimately improving teams’ ability to meet them.
    • Offering a potential solution to improve when SLOs are not met and error budgets are overspent.
    • Relieving team cognitive load when dealing with vast amounts of data–reducing burnout.
    • Releasing humans and teams from toil while improving productivity, innovation and the flow and delivery of value.
    • Supporting multifunctional, autonomous teams and the ‘We build it, we own it,’ DevOps mantra.
    • Completing the value stream cycle by providing insights around value outcomes that can be fed back into the innovation phase.”

    Mark Peters, technical lead, Novetta

    “True system observability means any process or event within any operational or development phase can be monitored by SREs. Systems with built-in observability provide SREs, as subject matter experts, the opportunity to examine events from different perspectives. The more observable the system, the more different places can be examined to help improve the overall flow. SREs can then create the feedback and design experiments to observe from different perspectives. If the event is showing functional difficulties and the only monitoring point is the input/output of the function and there is no process observability, SREs have to go back to the beginning to find events. If they can observe the entire process chain from commit to deployment, one can find the different areas. Think about the A/B cycle: Limited deployments are planned, and the load shifted gradually to ensure the new system can handle the increased functions. If the SRE cannot observe the function, then they cannot help improve reliability.”

    Ryan Sheldrake, field CTO, Lacework 

    “If you can ‘see’ or observe the complex and ever-changing environments that SREs are tasked with managing, creating and perhaps destroying, you can manage the associated risk posture associated with those environments and corresponding workload.“

    Vishnu Vasudevan, head of product engineering and development, Opsera

    “The top benefit for site reliability engineering (SRE) teams is the opportunity to work collaboratively with the business stakeholders and technology stakeholders to set goals and continuously improve. Based on these goals, SRE’s can create an approval process, which will help them understand where they are with respect to their own planning, security policies, quality metrics and operations practices. The ability to measure every release and verify the project helps improve speed to market and other factors once a robust observability practice is achieved. With DevOps orchestration across all the DevOps tools, applications being released and the different teams involved, SRE teams can then turn observability practices into a competitive advantage.”

    Sushant Mehta, senior manager, application development, Diyar United Company

    “Using observability, SREs can achieve a number of objectives in their day-to-day work, like identifying the root cause of production issues, faster resolution of issues and striving for self-healing infrastructure setup with no-code.”

    Tiffany Jachja, engineering manager, Vox Media

    “Every team that delivers software should be taking responsibility for their contributions to a software service. For SREs, having observability into an application means having the systems in place to help developers gain insights into how software applications function. Ultimately, it’s about building better software.”

    Parveen Arora, co-founder and director, VVnT SeQuor

    “SREs teams can leverage observability to get the following benefits:

    • To keep SLOs intact by detecting customer-affecting issues faster and rolling back before an issue affects the SLOs.
    • To have real-time health updates and transparency of information with regard to a service’s status. 
    • To create better workflows for debugging, optimizing workflows and resolving issues rapidly.
    • To simplify root cause analysis and investigation of hypotheses.”

    Jose Adan Ortiz, solutions engineer, Akamai Technologies

    “SREs are mainly concerned with the reliability of systems and usually monitor practices of toil, SLO, error, budget and stability to maintain systems working as expected.

    You could ask, ‘How can an SRE achieve such an integrated view of all systems components?’ The answer is observability. Without observability tools, it was impossible for an SRE to provide an effective response, fast RCA and analysis of data to improve SLOs.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “It can provide several advantages, including:

    • Detecting customer-impacting errors faster and reverting before SLOs are broken.
    • Fostering transparency and delivering real-time updates on the status of a service. This allows SREs to be more productive and saves a lot of time.
    • Developing better methods for debugging, optimizing and quickly addressing issues.
    • Allows for feedback loops, which are crucial in the SRE role.
    • To avoid downtime, the relevance of observability rises in real-world production systems. There should be proper notification processes in place.”

    Maciek Jarosz, DevOps and process expert

    “The benefits are quite great, I’d say. Unless one is living under a rock with one local system, then it’s rather inevitable that there will be dependencies here and there. And if you’re an SRE, then I’d say that you’d rather know a bit more about dependencies from other branches of your system—or other systems altogether—than less.

    Learn more about observability and similar topics by registering for an upcoming SKILup Day. 

  • Enterprise Blockchain Adoption Hinges on DevOps

    Enterprise Blockchain Adoption Hinges on DevOps

    There is a lot of excitement around blockchain right now, for a good reason. Production use cases continue to emerge across sectors such as manufacturing, energy, air travel, insurance and finance. Gartner predicts that by 2023, organizations using blockchain smart contracts will see a 50% increase in their data quality.

    Yet, Gartner also predicts that blockchain will reduce data availability by 30%. Before its use can reach ubiquity, blockchain-based application development has some hurdles to overcome. And if enterprises are to get on board, executives will need to see tangible proof of its value in the form of reduced expenses and increased profits directly correlated with blockchain adoption.

    “Enterprises aren’t going to change their business model to adopt a new technology,” said CasperLabs CEO Mrinal Manohar. Just as it’s difficult to dramatically alter the UX for established products, it’s similarly difficult to change the developer experience for established software production routines.

    I recently met with Manohar to discuss the limitations and the changes required to accelerate enterprise blockchain adoption. According to Manohar, much of it boils down to taking a DevOps approach—reducing energy use, enabling CI/CD, ensuring stable development environments and providing room for change and ongoing testing—will be critical to spur adoption. This could also mean abstracting complexity away from the developer and end users. However, once more production proofs are out there, the shift toward blockchain will be swift and it will be massive.

    What’s Hindering Enterprise Adoption?

    Enterprise adoption comes down to UI and UX, said Manohar. He predicts blockchain will follow a similar path as the internet. In its command-line days, the internet was only adopted by die-hard techies. But once visual-based actions were possible through the browser, consumer interest exploded.

    Similarly, blockchain might see more production use once the complexity is pushed to the background. “A technology is awesome when it’s 99% invisible,” said Manohar. However, at the moment, blockchain is 99% visible, he adds. For example, it isn’t easy to spin up a node and test a blockchain app. Lowering the requirements to 50% with more abstraction, simulation and integration with cloud providers could help tremendously.

    In general, Manohar believes that four key factors are hindering enterprise adoption:

    1. Enterprises need a lower energy footprint. Attaining high throughput on a public network without sacrificing decentralization and security is tricky. If blockchain drains operations when scaled, organizations may simply opt for a centralized data store. Therefore, enterprises will require a blockchain with minimal energy requirements.
    2. Large companies want developer environments that are similar to what’s already in place. In many ways, blockchain throws out the old playbook. But such a significant shift is a hard sell across multiple IT divisions. Large companies will require blockchain abilities that plug into the existing developer stack. Using a blockchain with familiar programming languages and plugins to popular IDEs like Visual Studio and IntelliJ will decrease onboarding effort.
    3. They need more control. Blockchains typically use immutable contracts. This is great for sustaining a shared distributed history, but Manohar believes that contracts need to be more malleable to enable continual upgrades. Furthermore, there is the issue of privacy when adopting blockchain. Some implementers don’t want all 100% of data to be on the public chain. Having the ability to maintain both private and public nodes for smart contracts could help enable more flexibility.
    4. Enterprises want ongoing support. Some companies will be autonomous using open source, but most enterprises will not adopt new or emerging technology without a support email attached to it, said Manohar. Thus, there may be a need for professional services and outsourced blockchain experts.

    Applying a DevOps Perspective

    Another big boon to accelerating blockchain adoption could be considering a DevOps perspective. To Manohar, introducing DevOps into blockchain requires more continuous updates, mitigations to avoid breaking change and simulations to enable better testing environments.

    An immutable blockchain infrastructure seems to be at odds with the DevOps creed of rapid deployment. Thus, Manohar said that choosing a blockchain that enables more mutability will help upgrade contracts and allow functionality to change over time. For core infrastructure changes that affect the entire public chain, the majority of validators must, of course, accept upgrades before they are distributed.

    Simple functionality, like a push notification, could ease this process to allow a quick Yes or No response from operators.

    Another potential concern is backward compatibility. What if the aggregate introduces significant breaking change? Manohar said that while this is technically possible, it’s improbable. “That would be a controversial upgrade,” he said, and validators have an incentive to keep a sturdy system intact. “They only do it if they think it’s better for the long-term health of the network.” But guardrails on this process will help avoid edge cases. Thankfully, if a change did disturb a minority of users, a blockchain can be forked. We’ve already seen this occur with Bitcoin Cash and Bitcoin, or Ethereum Classic and Ethereum, for example.

    Another shift that will help enterprises embrace DevOps in their use of blockchain will be better testing and deployment processes. It’s notoriously challenging to test blockchain applications while they are tapped into the broader network. Thus, engineers could benefit from a simulated runtime wholly divorced from the main network for testing purposes.

    The Future of Blockchain Development

    So, what does the future of blockchain enterprise adoption look like? Well, it appears we will continue to see new novel use cases emerge that use blockchain in innovative ways. For example, Manohar pointed to the use of blockchain to power an NFT digital twin, a patent marketplace, a tagging system for supply chains and the mortgage processes for a core banking system. Within these scenarios, he noted how blockchain is exorcising cost in many ways; smart contracts are being used to avoid legal fees, eliminate manual processing and improve fault attribution.

    Before blockchain can go mainstream, however, work must be done to bring other enterprises into the fold. Namely, it will necessitate more abstraction of the infrastructure layer. In this effort, low-code integration capabilities could help make API connections to ERP systems or cloud service providers more accessible.

    To inspire adoption, the economy must also change its perspective on what constitutes blockchain success. As of now, common KPIs are surface-level, like: How many wallets? What is the trading volume? Instead, Manohar believes we need to focus on proving actual cost savings from blockchain adoption. Once accountants are publicly reporting revenue gains, shareholders will demand that every company do this, he said.

    “Once that catalyst happens, adoption will happen very, very fast, and demand for blockchain in enterprises will be massive.” At that point, some years down the line, blockchain may truly power a new economy.

  • DevOps World 2021: 3 Sessions for Successful Scaling

    DevOps World 2021: 3 Sessions for Successful Scaling

    Your business has grown from a startup of five people to a full-blown organization of 100 … congrats! But, now what? The practices that worked for a smaller company may have worked as you first started growing, but now it’s time to scale operations to fit your new needs. Just like a kid outgrowing their clothes, your organization needs a new “wardrobe,” and scalability is key for long-term success.

    This year’s virtual conference—scheduled for Sept. 28-30—will offer a number of breakout sessions, panels and keynotes focused on scalability within enterprises. If you’re ready to scale within your business, here are a few sessions from this year’s conference to help get you started.

    From Startup To Enterprise—Sustainably Scaling

    Many organizations struggle to scale DevOps culture as they grow. Now it’s time to say goodbye to the startup phase and hello to thinking like an enterprise.

    Alston Rousseau, director of software delivery at Campspot and Kailene Cloud, director of talent acquisition at Bonusly, will walk attendees through the investment needed to sustainably scale operations, development and culture. Plus, they will share tips for finding more value in existing commitments to money spending, time and diversity in DevOps and how this approach applies to organizations with and without high compliance requirements.

    Scaling up Car Configuration: From a Statically Hosted Front End to Universally Rendered Services

    Over the past year, tech company Code Orange made the transition from a traditional API/SPA split to a much more technically challenging server-rendered SPA with full cache handover.

    In this breakout session led by Niels Hoiting, a developer at Code Orange, attendees will learn more about Code Orange’s transition from API/SPA split to server-rendered SPA while analyzing the pitfalls that can arise in the transition and how to optimize compute spend to best handle a specific workload.

    Leveraging CloudBees to Scale Satellite Ground System Emulation in Multifaceted Virtual Environments

    Aerospace and defense technology manufacturer Raytheon Technologies has successfully implemented CI/CD pipelines for the test and near-operational integration of both software and hardware for a global satellite ground system.

    In this breakout session led by Casey Jackman, deputy of GPS Product Factory at Raytheon, attendees will discover how Raytheon uses simulated satellite control stations in virtual private clouds for CI, test and check-out. Additionally, Casey will share how the team met challenges in initial pipeline generation between multiple disparate target environments with AWS and on-premise data centers.

    Think it’s time to scale your organization? Register now for DevOps World 2021 to get started.