Category: Enterprise DevOps

  • 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!

  • 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.

  • 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.

  • How to Achieve Cloud Operational Excellence

    How to Achieve Cloud Operational Excellence

    Cloud operational excellence means delivering the right mix of cloud-based services at the optimal cost and quality to support your organization’s mission and strategy. You might be thinking, “Why go to the trouble? Isn’t ‘almost good enough’ sufficient?” It turns out that it matters—a lot. The difference between the top 10% and the bottom 10% in cost per relevant delivery metric can vary by an order of magnitude or more.

    In the mid-1990s, Gartner acquired an IT metrics firm called Real Decisions. They offered benchmarking services so customers could compare their IT efficiency with similar organizations. With hundreds of “Global 2000”-sized customers, their database was rich. Over time, the Real Decisions team refined their catalog of metrics and enriched their data with repeat studies over time, to develop indices of efficiency. 

    Within their user population, the difference in cost per unit of productive work was 11 times better in the top 10% compared with the bottom 10%. That doesn’t mean 11% better, it means 1,000% better. 

    Note that the user base was self-selected. All participants wanted to get objective metrics of performance relevant to their business goals and paid for extensive studies involving questionnaires, financial audits and technical benchmarks. Notably, all participants had cost recovery programs (beyond chargeback) in place. The bottom 10% of this segment is still within the top 10% of the IT industry—and their score is 11 times worse than the best of the best. 

    Which raises the question: What is the industry average for IT efficiency? Is it possible that the hundreds of benchmarking users are all doing IT wrong, and the search for relevant metrics is misguided? I think not. 

    Choosing the Right Metrics

    In 1911, Fredrick W. Taylor published The Principles of Scientific Management, which discussed approaches to optimizing two important variables: Output quality and worker compensation. Taylor recognized that successful firms work collaboratively, with management and workers jointly setting goals and developing methods and tools to achieve both profitability and proportionate compensation. Nowhere in this text—or in any of his recorded speeches or documents—does he say, “If you can’t measure it, you can’t manage it.” He never said that for two reasons: First, he did not believe it; second, it is not true. What he did emphasize was that if you do measure it, you will manage it. That was a warning: Pick the right metrics or you will exert effort pursuing a meaningless goal. 

    Here are some potential cloud performance metrics compiled from several cloud providers and users across various industries, not-for-profits and governmental agencies: 

    • Service Metrics 
      • Reliability – mean time between failure (MTBF)
      • Availability – Uptime, expressed as a meaningful percentage of demand
      • Serviceability – Mean time to repair (MTTR)
    • IT Metrics
      • Capacity 
      • Latency
      • Bandwidth
      • Response time
    • Strategic Metrics  
      • Business agility 
      • Customer engagement 
      • Customer reach 
      • Financial impact 
      • Solution performance 

    The journey to cloud excellence starts with developing the metrics that are most relevant to your business goals. Picking the right metrics with the right scale matters. As a rule of thumb, generally right beats precisely wrong. 

    Sustaining Excellence 

    After you agree on a set of metrics that are both statistically reliable, repeatable, objective and aligned with your firm’s mission, how do you achieve and sustain excellence? 

    In the 1970s, the U.S. Department of Defense bought a lot of custom software. Sometimes it worked well, other times it didn’t. So, the DoD funded research on code quality. It turns out that the key difference between great and mediocre quality code flowed from how the organization managed problems. More specifically, how did the team react to an unexpected event? The spectrum runs from confusion and dismay through fire drill chaos to calm, rational assessment and remediation. That methodology gets baked into the code itself. This study produced the Capability Maturity Model (CMMi), which was created by the Software Engineering Institute at Carnegie Mellon University. 

    The CMMi framework identifies five levels of process maturity. A simplified assessment of an organization’s process maturity level comes down to two questions. First, is there current comprehensive documentation for the process, including how to deal with defects? If the answer is yes, the organization is at level three or higher. If the answer is no, the second question is, “Does anyone know what’s going on?” If the answer is yes, that’s level two; if no, level one. 

    A level one organization has no standard method in place to deal with problems. When something goes wrong, everybody grabs tools and tries to figure out what went wrong and how to fix it. Organizations like this do not spend much on training or analysis. Their focus is continuing to produce whatever they are trying to make. Over time, an individual may develop expertise in diagnosing a component, and when things go wrong, the call goes out to “Get Fred in here!” to troubleshoot the problem. Organizations with pockets of expertise are moving into level two. Most organizations fall within one of these two levels. 

    Organizational transformation is very difficult, and often requires significant changes in the management team, as well as funding different activities. Training and communications skills are crucial to proceeding beyond level two. Management rewards heroes who can shoot the most difficult bugs. They get the big bonus, the promotion, the better office, a parking space near the door. This behavior reinforces the culture of heroes. But moving forward requires the heroes take on a new role.  

    Once the organization creates documentation, it is on the path to level three. Note that these transformations are wrenching. It is not easy to tell the heroes that their greatest value to the organization is now how well they can write or teach. But with proper management attention, it can be done. And the benefits of moving forward are many: 

    • Dramatically fewer crises. Staff could make plans and keep them – no emergencies interrupting a family gathering, a school event, or a get-together with friends. 
    • High quality code. Maintenance tasks became much simpler, and customers experienced improved reliability. The documentation was helpful, and troubleshooting became routine rather than overwhelming. 
    • Reliable planning. In a mature organization, plans hold true because they are based in proven metrics, continuously validated processes and uniformly high competence within the team. Project estimates are accurate because the data stems from reliable, repeatable evidence. 

    Cloud excellence is not a phantom or an unachievable goal. It is the result of clear thinking and sound documentation. Over time, practices improve, skills build. To quote Macklemore, “The greats weren’t great because at birth they could paint, the greats were great because they painted a lot.”  With practice and focus, your organization can achieve cloud excellence.

  • That Other Continuous: Data Protection

    That Other Continuous: Data Protection

    Looking around at things to add to our current project’s toolchain (that is one of the reasons we do these side projects; to check out all sorts of new ideas/tools/etc), and researching the company where a former coworker is the CMO, I was drawn into the resurgent world of continuous data protection (CDP). It is interesting that we could end up adding CDP to the list of ‘continuous’ activities, like CI/CD/… CDP, even though CDP was named long before any of our DevOps or Agile terms were born.

    The whole idea of CDP is that it is always backed up, so you are continuously protected. It largely failed when first introduced because it massively increased both the cost and complexity of your storage environment. Essentially, it required a hot copy of all of your storage. Not something most enterprises were willing to invest in. I mean, it was friggin’ expensive. And it used virtualized storage, which no one wanted to mess with. Long story short, at the time, virtualized storage introduced issues no one wanted to deal with.

    But several things have changed over the years, and it is interesting to see where CDP concepts have cropped up. You see, today it is being used to protect companies from ransomware. It’s still a bit of complexity, but we’ve become experts at hiding complexity. It still requires a lot of storage (I would argue that the current versions I’m seeing require more storage than the original CDP solutions did), but when your environment is taken over by ransomware, a clean machine can be used to restore data to a point before the ransomware took over. From a “continuous protection” standpoint—giving it a modern meaning along the lines of “continuous testing”—that is an astounding feat.

    The way it works—at least the way that the current implementations I’ve looked at work—is pretty simple at heart, though as my former coworker likes to say, “Easy in concept, difficult in implementation.” It keeps every write ever made to storage, with time and currency markers. So it knows what the disk currently looks like, but it can also get to what the disk looked like at 12:33 am yesterday. Or January first, or a year ago… You get the idea.

    It uses a ton of space because there is an implied truth here—nothing is destroyed. In traditional storage, if you change a document and hit save, the document is written over. In the new iteration of CDP, if you change a document and hit save, the changes are recorded, but the original is not altered. Call it “non-destructive writes,” if you will.

    It is worth checking out. The concepts are huge, and offer protection that is otherwise in short supply. If you have a dedicated DevSecOps team, they’re the ones I’d point at it, since the big reason for using this is a security reason at heart (though there are other uses; I’m currently gushing about security because this is a big deal).

    I’ll get back on track and report back about things directly in the toolchain for our newest DevOps project next week. I thought this was worth writing about, since most of you all could use the concept, even if only for peace of mind. You’re rocking it! Protecting your work against the newest range of attackers is just common sense. It’s worth seeing if the modern iteration of CDP is for you.

  • Federal IT Must Embrace Automation

    Federal IT Must Embrace Automation

    In the private sector, an automation explosion is underway.

    One major retailer, for example, is using a new automated system to increase speed and accuracy in how freight is handled at its regional distribution centers. Another retail giant is relying on new automated processes to replenish store shelves more efficiently, reduce excess inventory and free employees from mundane sorting tasks.

    They are among the retailers using automation to make the networks that interconnect all their locations easier to deploy and manage. But what about federal agencies, which are among the largest enterprises in the world?

    The story there is more of a mixed bag.

    At first glance, it may seem like apples and oranges to compare government agencies with some of the world’s largest retailers. But both are responsible for serving millions of people during a time of dramatic digital advancement, which requires significant reengineering of operations, systems and processes.

    In the case of federal agencies, digital pressures have intensified as citizens have come to expect service experiences similar to those they encounter every day in the commercial sector, and as the volumes and types of data that agencies must deal with have surged.

    The Benefits of Automation

    Agencies can leverage intelligent automation for a range of benefits, from relieving employees of rote, low-value work so they can contribute in more meaningful ways to making digital services faster and more responsive through the automation of manual, backend processes.

    Let’s say, for example, that a government website serving millions of citizens is prone to slowing down and even crashing. Automated software tools that analyze huge volumes of network data can proactively identify a potential issue and fix it before it becomes a problem.

    Sounds great, right? But uptake of automation technologies in federal agencies remains a work in progress.

    A recent survey found that 63% of federal agency executives thought they could benefit from intelligent automation and that 38% have already started implementing it. However, a large number–30%–remain on the fence and said they didn’t know if automation could help them.

    Interestingly, automation’s top benefits as perceived by the survey respondents were: Moving employees away from redundant or low-value work, reducing errors and offering a better experience to citizens and other users. Reducing costs was lower on the list, which is a good sign because it shows that more in the government sector are recognizing automation’s strategic value rather than fearing it as a job killer.

    Federal Adoption of RPA

    As a reflection of how automation is changing the nature of work and making employees’ jobs more interesting and productive, the federal government has stepped up a push to adopt robotic process automation (RPA) over the last few years. RPA is a technology that uses software robots to automate highly repetitive tasks that people would otherwise perform manually. This frees up human employees for higher-value work.

    These tasks can include extraction of data from websites and email text into a structured form for processing, data reconciliation and monitoring and responding to common IT and networking issues.

    In 2018, the White House Office of Management and Budget directed federal agencies and heads of executive departments to identify more opportunities to streamline operations via RPA.

    In 2020, the General Services Administration estimated that current automation programs “operating within agencies are achieving roughly five hours of workload elimination per employee. If the government deployed RPA at scale and achieved only 20 hours of workload elimination per employee, the net capacity gained would be worth $3 billion–and that is only scratching the surface.”

    The GSA leads the federal RPA Community of Practice to help agencies overcome the technical, management, and operational challenges in designing and deploying RPA programs.

    “At a government-wide level, RPA can represent a profound change, with the potential to empower non-IT professionals and process owners with the tools to automate a significant share of their workload,” the group’s report said. “RPA is considered transformative because it establishes the building blocks for artificial intelligence in terms of information technology infrastructure and task standardization. With effective RPA deployment, machine learning and intelligent automation are only a few, manageable steps away.”

    According to the group, “many agencies across the federal government have initiated RPA programs to automate tasks of varying complexity. Automations developed to date have focused on multiple functional areas including finance, acquisition, IT, human resources, mission organizations and security/mission assurance.”

    My own experience in working with federal customers is that many are at least dipping their toes into the automation waters, but not quickly enough and certainly not at the pace seen in some parts of the private sector.

    Why the continued reluctance? I think much of it comes down to trust. Worries remain that automation will take jobs when, in fact, machines should be thought of as non-human team members who take care of the drudgery while the humans contribute their knowledge and creativity to more important work. Federal enterprises should embrace the opportunity to test automation to prove it works as they expect, similar to interviewing a new employee. This is how to gain the trust needed to deploy automation to augment humans’ work.

    Automation also faces resistance from older employees who, on the verge of retirement, aren’t interested in learning new technology.

    The fact is, though, the federal government is on the cusp of an automation boom. More and more, it will become critical to agencies’ success. The time for fear and mistrust is over.

    Automation is here to stay, and agencies should embrace it.

  • Majority of Organizations Now Adopt Multi-Cloud

    Majority of Organizations Now Adopt Multi-Cloud

    As IT’s digital footprint grows, its cloud footprint is rising both in size and complexity. As a result, most organizations have matured into multi-cloud operators. A multi-cloud approach empowers different divisions with the autonomy to select the right computing environment for their needs. It also enables a lift-and-shift ability to port workloads across cloud service providers (CSPs) when needed. Adopting a multi-cloud model could bring performance benefits, cost savings or better scalability, all while encouraging a more vendor-neutral stance.

    We’re in a multi-cloud world. A recent HashiCorp study found three out of every four organizations are already multi-cloud. This is a staggering increase from just a few years ago when mono-cloud was more accepted, and operators had zombie-like allegiance to AWS. The uptick in multi-cloud signals the maturity of offerings at other CSPs, like Azure and GCP. It also signals differentiation among clouds as each hones in their unique value propositions.

    HashiCorp’s inaugural State of Cloud Strategy Survey offers some very clear results about the state of multi-cloud adoption. Below, I’ll review major takeaways from the report to better understand the state of multi-cloud adoption. To sum it up, large organizations tend to benefit most from multi-cloud adoption, as there are still significant roadblocks to truly reaping a sizable return from a multi-cloud status. Yet, more infrastructure automation may help companies of all sizes respond to multi-cloud complexities.

    The Multi-Cloud Era

    DevOps truly operates in a multi-cloud era. The report revealed 76% of organizations are already multi-cloud; that leaves only one in four companies leveraging a single cloud. And, that trend won’t stop—within two years, 86% predict they will be multi-cloud operators. The study also confirms that the larger a company is, the more likely it will adopt multi-cloud—94% of large enterprises with 5,000 or more employees are multi-cloud.

    So, what’s driving this cloud fragmentation? Well, 34% of respondents cite digital transformation as a top driver for multi-cloud adoption. In the race to meet new digital innovation demands, multi-cloud has emerged as a strategic force. To enact this rapid change, many organizations are investing in a cloud center of excellence (CCoE) to guide cloud transformation efforts. A CCoE is most common within large companies with a cloud budget of $5 million or more.

    Speaking of budgets, cloud spending is going through the roof. In 2020, only half of companies met their projected cloud spend, and 39% of companies overspent their allotted cloud budgets. As I’ve covered before, cloud-native costs are notoriously difficult to identify and trim. Without the proper guardrails to manage spending, surprise data egress fees or hidden server costs can strain the cloud checkbook. As it stands now, 40% of companies lie in the $100,000 to $2 million per year range, and 6% of enterprises are investing $50 million a year or more into multi-cloud. This spending will likely increase in the coming years as cloud reliance expands.

    Enterprises Benefit Most

    So, which clouds are companies using? If we compare cloud adoption, AWS is a clear market leader; 88% of companies use AWS, 74% use Azure and 61% use GCP. AWS’s hegemony is not expected to fade in the next two years. Yet, while AWS usage will remain the same, competing CSPs will experience modest increases. This is likely due to Azure and GCP making gains in geographical zones outside North America, such as Asia-Pacific and Africa.

    In terms of technology used in cloud environments, open source software (OSS) is a popular choice. Cloud-native open source projects, such as Kubernetes, OpenStack and Terraform, have taken on a life of their own, with vibrant community support. However, not all shops build upon OSS and run it themselves. Somewhat ironically, we’re seeing more managed OSS emerge. One stand-out area is provisioning, where 42% of organizations build with open source and run it themselves.

    On the whole, multi-cloud is working at most enterprises, with 53% of survey respondents saying multi-cloud has helped achieve their business goals. The top benefit of multi-cloud is digital transformation, at 34%. This is followed by avoiding lock-in (30%), reducing cost (28%) and scalability (25%). But multi-cloud does not treat all companies as equals; the likelihood of multi-cloud success increases as the company size increases. Less than half (42%) of small companies say they have multi-cloud success, which jumps to 64% for large enterprises. With fewer resources for support, multi-cloud may be less beneficial for startups and small to medium businesses. In fact, 41% of professionals say a lack of in-house skills inhibits their cloud success.

    Challenges in a Hybrid Multi-Cloud World

    An ongoing talent gap is just one potential challenge to cloud success. Just over half (51%) say cost concerns are a top inhibitor to their cloud program success. Hybrid cloud complexity is another prominent challenge, with 35% of organizations citing it as a major cloud obstacle. Many enterprises are still grappling with the remnants of legacy on-premises estates. But technical debt is not the only reason for hybrid modalities. Surprisingly, large platforms even have constructed their own data centers or used colocation as an intentional strategy.

    Security is a top cloud inhibitor, according to 47% of IT professionals. The leading cloud security concerns include data protection (40%), data theft (33%) and regulatory compliance (31%). The myriad cybersecurity threats evolve each day, and cloud technologies are not immune; for example, web APIs are now a significant threat vector. A separate report found a 300% increase in malicious API traffic in the past six months. Other issues, such as exposed keys, insecure defaults and misconfigurations are known to hamper cloud-native infrastructure.

    Contrary to popular belief, nearly half (46%) of companies reported that COVID-19 has not quickened their cloud adoption. This reality could indicate that cloud migration has been planned for years, and recent adoption is only part of an ongoing trend. The study found that the pandemic did, however, accelerate things like infrastructure-as-code (IaC), container orchestration, compliance and governance and other operational factors.

    Infrastructure Automation Supports Multi-Cloud

    Multi-cloud feels like an inevitable result of accelerating cloud adoption in a more diversified market. Rising multi-cloud use is also arguably in line with Conway’s Law. As organizations develop more and more digital experiences across new verticals, the platforms and backend processes to support these initiatives will inevitably grow more and more complex.

    To mitigate some of the issues posed by multi-cloud, many organizations are turning toward increased infrastructure automation. In fact, 70% of those surveyed said infrastructure automation tools are extremely important to their organization. Of these tools, provisioning automation (75%) is the most popular kind in use. Automation for other areas, like networking (58%), security (50%) and app development (69%) follow.

    Hashicorp’s State of Cloud Strategy Survey boldly announces, “Welcome to the Multi-Cloud Era,” and its findings back up that sentiment. For further insights, you can view the results freely on this website.

  • How to Achieve AWS Competency Accreditation

    How to Achieve AWS Competency Accreditation

    For businesses in the early stage of their ventures, proving that they have the expertise and technical know-how when it comes to cloud technology can be difficult. An acceleration toward digitization due to COVID-19 and an increasingly crowded cloud market, dominated by the big players, means that simply shouting about your skills in cloud engineering and DevOps isn’t enough to get noticed.

    But what if you can work alongside these giants? Joining forces with expert brands and entering into endorsement partnerships can propel your business forward by supplementing it with seasoned expertise. Accreditation, if you can achieve it, can give you a stamp of approval and reassure prospects that you have the relevant knowledge to support their digital transformation efforts. Collaborating with industry leaders on skills accreditation programs is a great way to demonstrate your capabilities and provides clear goalposts to work toward when it comes to building and learning.

    So, how do businesses achieve this status and what are the long-term benefits of the process?

    Become an AWS Partner

    Achieving accreditation as an AWS DevOps Competency Partner takes a lot of hard work and investment into building the technical skills required to reach such a high standard–logging and evidencing every action your team takes is no mean feat. From beginning to end, the course takes around six months. The process begins with researching and selecting which specific competency your team is interested in achieving. It’s important to understand which competency your business is most suited to, so doing your homework is key. From there, there’s a lot of work to evidence, certificates to achieve and reviews to undergo. Becoming an accredited AWS partner brings a multitude of benefits to your brand, so it is well worth the investment.

    Top Tips for the Accreditation Process:

    Create detailed accounts of your work: To become a certified DevOps partner, businesses need to evidence four case study examples; two public and two private. As such, it can be useful to bring in a tech writer to consolidated your notes and observations throughout the process. We began, for example, with a technical exploration from the team to understand the best case studies to put forward; our work had to be clearly evidenced with strong examples and the documentation to back it up which took a considerable amount of time to pull together. Maintaining clear and detailed accounts of previous work can prevent any delays. This information is firstly analyzed by AWS to check that it met the specific requirements before being passed on to be examined by a team of external auditors, so every detail counts when it comes to showcasing your work.

    Prepare the marketing team: As part of the process, businesses are required to have certain marketing collateral in place across their website to aid with lead generation. For the DevOps competency certification, we needed to evidence three technical blogs–businesses applying for the certification need to ensure that the content best reflects their expertise in the given competency. Once the accreditation is finalized, the partnership should be displayed on the site. Even if a business is tech-agnostic, demonstrating your skills in a particular type of cloud engineering is highly valuable to your brand and AWS is a respected platform to use.

    Advance technical training in the workplace: Having members of the team qualified in cloud engineering is another requirement for accreditation. For DevOps, we needed eight people on the team to have achieved their associate certifications and four to have achieved professional certifications. To fulfill this requirement and ensure we’re on top of our game when it comes to cloud training, we’ve invested in third-party tools, provided access to LinkedIn Learning programs and we give our people additional time off from client-facing work to prepare for their exams. Building and learning in tandem is the fabric of our culture, and a similar approach would benefit any company looking to achieve certification status.

    The Benefits of AWS Accreditation

    Being able to showcase a close association with a major player such as AWS opens up a number of doors for smaller businesses. Operating within this kind of business ecosystem provides the opportunity to demonstrate a business’ DevOps and technical skills to an enormous global audience which can drive new business conversations and drive quality leads. Confirmation that your business is a trusted partner for a major cloud organization will ensure that prospects have confidence in your capabilities and you’re taken seriously as a technical player in the market. Building confidence within your teams and supporting them in their learning is an investment that will pay huge dividends.

    Working alongside AWS as an accredited DevOps partner gives us a springboard to talk about our work and engage with other players in the market. The accreditation is a fantastic talking point and definitely gets you noticed in the cloud community–plus, you will be taken more seriously as a partner.

    Investment in Cloud Tech is Key for the Future

    As businesses everywhere begin to operate in an increasingly digitized environment, technical skills and cloud expertise are a necessary investment for any business. Working toward coveted industry accreditations while prioritizing long-term skills training is imperative. It’s a competitive, buoyant market for cloud engineers and DevOps at the moment; opportunities are at their fingertips and if they aren’t feeling fulfilled by their current work, they’re likely to look elsewhere. Investment in training and nurturing growth in this way breeds employee engagement and loyalty. For a company to thrive technically, it needs to host a wide range of diverse talent and be able to retain it. Learning opportunities should always be the key focus.

    The shortage of this talent means it’s critical to advance the business’s cloud expertise by pursuing recognition from major global players like AWS. Providing advanced training and certification opportunities for your people will ensure long-term talent retention while making the business a leader in cloud engineering. That’s pivotal for long-term success.

  • CloudBolt Survey Shows DevOps Frustration in the Enterprise

    CloudBolt Survey Shows DevOps Frustration in the Enterprise

    A survey of more than 200 senior IT leaders at organizations with more than 1,000 employees published today finds only 4% consider their organizations to be experts when it comes to continuous integration/continuous delivery (CI/CD).

    Conducted by CloudBolt Software, a provider of a platform for many IT environments, the survey also found only 11% consider their CI/CD infrastructure to be reliable. Another 69% said their CI/CD infrastructure was somewhat reliable, while 21% said their platforms were somewhat unreliable or not reliable at all. A full 85% also report they regularly test the infrastructure they rely on to drive DevOps processes.

    Overall, the CloudBolt survey finds only 5% of respondents report their organization is deploying code multiple times a day. Most respondents (85%) said their organization only deploys code on a weekly or monthly basis.

    A full 70% said that, on average, it also takes multiple days or even weeks to set up a pipeline. Nearly two-thirds (63%) said there are too many manual processes involved when setting up pipeline infrastructure. More than half (56%) also noted they have no automated processes for post-deployment tasks.

    More than half (53%) said it is also challenging to proactively detect infrastructure issues, while 55% said it is difficult to create a consistent CI/CD pipeline environment across multiple development teams. Improving those pipeline environments requires speeding up the process of provisioning infrastructure through automated processes (70%); continuously detecting infrastructure issues to reduce testing challenges and failures (62%) and simplifying remediation of infrastructure issues proactively (56%), according to survey respondents.

    The CloudBolt Software survey specifically identifies issues organizations encounter when employing Terraform to manage infrastructure-as-code (IaC). Only 5% of respondents said they were “very satisfied” with using Terraform and another 75% reported they are somewhat satisfied. Top challenges include difficulty using it in on-premises infrastructure deployments (62%), lack of Day 2 management for deployed resources (53%) and governance (42%). Only 2% of respondents said they were employing Terraform to deploy 75% or more of their infrastructure. A full 90% noted that Terraform requires more custom-coded integrations with other critical tools and systems to work properly.

    Finally, 29% said their organization lacks specific Terraform expertise. The most sought-after Terraform capabilities are enabling non-Terraform experts to easily deploy infrastructure using Terraform; ensuring that only Terraform plans with IT “guardrails” are executed and the ability to visualize and cost-optimize infrastructure deployed by Terraform. More than a third (35%) want to simplify deployment of on-premises infrastructure when using Terraform.

    Jeff Kulkowski, CloudBolt CEO, said the survey makes it clear there simply isn’t enough expertise available to implement DevOps  best practices at scale without enabling IT administrators—that often lack programming expertise—to manage infrastructure and DevOps platforms. That requirement creates the need for an IT management platform based on a set of visual tools that enables DevOps professionals and traditional IT managers to work more collaboratively, he added. DevOps teams can manage IaC whenever they desire, but it’s also crucial to enable IT operations staff to manage IT infrastructure alongside those teams.

    Obviously, DevOps as an IT discipline still has a long way to go before it is pervasively adopted across enterprise IT organizations. The challenge now is to remove many of the low-level barriers that conspire to block IT modernization initiatives.

  • So Many Options, So Little Time

    So Many Options, So Little Time

    So many language/framework options, so little testing time, that is.

    Recently, two projects I was working on drove me to check out a breadth of languages and/or frameworks to handle cross-platform development. While Unity and Unreal have traditionally been my game platforms of choice and I typically use Xamarin for cross-platform (though native development is more common for us on both Apple and Android), I decided I needed to do the occasional sweep to find out what is new out there.

    The two projects are a game on which I’m helping a new game developer learn and a graphics-heavy application that is unsuited to web development. Both would work best in a cross-platform environment; both would benefit from a game engine’s graphics manipulations. But both could be done in any language that supports graphics, as there isn’t a heavy physics requirement to the game.

    So I went looking at what’s available now and how it fits. From React Native to Godot to Flutter and even Kivy, I kicked the tires on each, got them running, ran and traced samples, wrote some code of my own, even talked with friends that were using them to get their opinion.

    Alternate frameworks languages

    The one thing that came through loud and clear? There is no way that security and testing are keeping up with this language/framework proliferation. Kivy has a language (more of a specification than an actual language, but still—source code) that can run on top of Python (it’s not required to use the framework, but it’s kind of assumed you will if the app gets beyond a certain size); Godot has a language that is integral to the framework and that you use pretty much everywhere. React has a ton of add-on code and both Flutter and Dart are new languages.

    I like stuff from each of them. I don’t like that we’re going to use them in ever-increasing amounts and we’re going to expect testing to stay on top of those implementations. Each of these platforms/languages/environments has a large following that is doing some of the testing, but since they’re all relatively new, “How much testing?” is a valid question. And tests have to be done in those languages, implying that those writing need to know them and so do testing teams.

    Where did we end up? We haven’t made a final decision yet, but taking input from the person I’m mentoring, coworkers and those who are using each of the above, we’ll probably end up using Godot. For 2D apps, it is the bomb. Our team is small, so I can offer my knowledge of Godot to shore up testing and everyone agrees that its Python-like language is acceptable, while the graphic design element is nicer than the competition. Both applications will benefit from Godot’s graphics processing capabilities and the game will benefit from game elements built into the Godot Engine.

    Here is an interesting side note: All of the products we looked at are open source. Both of the default products that we (and just about everyone else) would choose for the game are commercial. That’s interesting, but we don’t need the weight of those commercial solutions for a simple 2D interactive game/app.

    For you all, the questions might be harder to answer. With larger projects come larger requirements for source size, test, you name it. Choose carefully, with an eye on the future. Personally, I think React Native, Godot and Flutter would all be good choices for cross-platform applications, with Godot the best solution for cross-platform 2D games. And all three are likely to be around with a good size following for a long time, making them safer choices. That is less clear with Kivy, though the popularity of Python appears to be driving growth in Kivy use.

    Whatever you choose, plan for all phases of development, not just writing code. That’s true of everything, but new cross-platform tools are complex beasts, so it is worth reminding you all.

    And hey, if you have a cool app you developed with one of these tools, point me to it. Always good to see what you all are doing, and nice to see the breadth of solutions these languages can create.