devopsy.kinsta.cloud

Category: DevOps Culture

  • 22 Engineering Leaders Weigh in on APIs

    22 Engineering Leaders Weigh in on APIs

    Every business today is a digital business … and if it’s not, it will be soon.

    A recent survey by Deloitte found that digitally mature companies are better able to navigate rapid change and, as a result, perform much better financially.  Nearly two-thirds of survey respondents asserted that organizations that don’t digitize in the next five years will be “doomed.”

    Application programming interfaces (APIs) are the cornerstone of these digital transformation efforts. APIs aren’t just technical conduits that let applications communicate with each other. In a software-driven world, they allow developers to build services more quickly, enable innovation, open up new markets and drive competitive advantage.

    A new State of the API report from Postman, which surveyed 28,000 developers and other tech pros, offers a vivid snapshot of APIs’ central role in modern organizations. It showed that API-fueled innovation has helped companies respond to the pandemic; that the global API ecosystem is growing; that developers are spending more time than ever with APIs and that almost everyone believes investment of time and resources into APIs will increase or stay the same in their organizations for the next 12 months.

    To learn more about APIs’ status in the enterprise, I’ve spent part of 2021 interviewing 22 engineering leaders from various companies for my podcast, Breaking Changes. I wanted to dive deeper into how and why these leaders view APIs as critical to business strategy and hear what lessons they’d share with others.

    Here, in 20 bite-sized chunks, are the recurring themes:

    Business. The greatest value generated from API operations is rarely directly from any single API, but around the partner enablement APIs make possible. Over and over, companies see that building an API ecosystem helps extend their business’s reach and deepens the connection with partners and customers.

    Strategy. Without proper planning, an organization will always be stuck in reactive mode when it comes to the applications that API operations are powering. It’s much better to have a comprehensive API strategy.

    Third-party relationships. Reliance on third-party systems—the vast supply chain of partners and vendors that organizations share data with via cloud-based technology—is exponentially increasing, pushing organizations to develop a more formal and external API strategy.

    Resources. The resources surrounding API operations need to speak to developers, support them and help make their lives easier as they work with a company’s APIs.

    Governance. It’s important to be cautious in automating governance at the pipeline level before developing relationships across teams and a centralized API governance approach is vital, too. API governance is the practice of applying common rules and security policies for APIs. 

    Management. The management of APIs is a continuous journey and not a destination, requiring a significant amount of planning and attention to reach desired objectives.

    Global. We are all increasingly reaching a global audience with APIs, and every organization’s message and resources need to reflect the increasingly diverse audience.

    Multi-Protocol. The future of APIs is multi-protocol, requiring a diverse toolbox of API protocols and patterns to properly grow ecosystems over the next decade.

    Enablement. Companies need to be enabling their API development teams, not governing them; making sure they have what they need to do APIs well while also failing safely.

    Regulations. API regulations are here and are pushing mainstream enterprises to become technology companies, requiring that they have an API strategy for the future.

    Mobile. The world reached a milestone in 2019: There are now more cellphones than people. APIs are how digital resources are made available on these devices in both leading and emerging markets.

    Opinionated. Informed and opinionated approaches to the API life cycle will make a bigger impact than any single technology used in the infrastructure stack.

    Intelligence. There is a massive opportunity in deriving intelligence in aggregate across the millions of API requests we make each day across core business applications.

    Quality. Organizations should prioritize not just testing APIs but testing the API tests themselves. This ensures a level of quality and reliability across all APIs, regardless of the team working with them.

    Education. Ensuring that teams have the proper ongoing training and education around the API life cycle must be a top-line priority across API operations.

    Authentication. The authentication layer of the API infrastructure holds a wealth of intelligence. Having humans study this dimension is critical for security.

    Data. Challenges and opportunities at the API data layer are massive, and machine learning is giving teams an exoskeleton to support failing and iterating faster during development.

    Privacy. Ensuring that privacy is a basic building block of the API life cycle helps developers focus on what they do best, resulting in higher-quality applications that also respect privacy.

    Observability. API analytics have matured in the last few years; becoming much more about observability across the API infrastructure and helping organizations see and respond to what matters.

    Open Source. Open-source technology is an essential part of growing and supporting an API ecosystem, providing both the technical and human nutrients needed to be healthy.

    By keeping these 20 points in mind, organizations can maximize APIs’ role as an extremely powerful mechanism for leveraging data and application functionality for business success. APIs will underpin digital transformation for many years to come, so it’s important to cover all the bases.

  • Is TypeScript the New JavaScript?

    Is TypeScript the New JavaScript?

    While JavaScript is frequently the language of choice for all sizes of frontend and backend applications, it’s not the only option; nor is it necessarily the most efficient or cost-effective. Increasingly, TypeScript is becoming the go-to language for app development—particularly for larger apps. The time- and cost-saving benefits are significant enough that some organizations are even taking projects initially started in JavaScript and migrating them to TypeScript. 

    What is TypeScript?

    While the number of programs written in JavaScript has grown exponentially, the programming language’s ability to express the relationships between different units of code and mitigate coding errors early on hasn’t kept pace. Along with JavaScript’s inconsistent semantics, this makes JavaScript-driven app development difficult to manage at scale.

    Released in 2012, TypeScript was created to address JavaScript’s deficiencies in developing large-scale apps. It’s an open source, strongly typed programming language that builds on JavaScript by adding optional static typing. Types enable structuring and validating code before it’s executed, which is beneficial when developing large apps. They also provide additional information about code, which serves as better documentation for other developers and facilitates collaboration.

    TypeScript is a superset of JavaScript, which means any JS code is also valid TS code—provided the TS configuration is set to be compatible with it. It outputs code in pure JavaScript and allows developers to liberally use JS libraries, tools and frameworks. It runs on Node.js or any browser that supports ECMAScript 3 or higher. It also supports object-oriented programming features. 

    JavaScript Drawbacks

    JavaScript is one of the world’s most popular programming languages and works extremely well for small projects. However, its disadvantages—many of which affect project costs and code delivery time—make a strong case for considering alternatives such as TypeScript, particularly for larger projects.

    Most of these drawbacks have to do with the lack of types and compile-time error checks, making JavaScript less than desirable for server-side code in enterprises and large codebases. The following are just a few of its disadvantages:

    • JavaScript employs dynamic typing, which means scripts can compile even if they contain errors that can prevent them from properly running.
    • Because JavaScript is dynamically typed, it allows one variable to have multiple properties assigned to it. It doesn’t instantly let developers know what a variable can contain. That makes it easy to assign the wrong properties.
    • Since JavaScript is an interpreted language, errors can only be found during runtime. Code needs to run before being tested and validated, so it can take considerable time to find bugs and errors in JavaScript code.
    • To eliminate inaccuracies, it’s necessary to manually verify types and the syntactic correctness of the code. This lengthens development time and extends the delivery cycle to production, increasing development costs.
    • JavaScript code is executed on the client side so it’s viewable to the user. As a result, bugs and oversights have the potential to be exploited for malicious purposes. 
    • Lengthy onboarding of new developers can result because developers must figure out the properties of the structures they’re working with, as well as the data types. While JSDoc can be used for documenting code and annotating types, there’s still the need to synchronize the actual code and documentation. The lack of synchronization, in turn, can mislead developers and complicate the introduction of new, business-requested features.
    • JavaScript is prototype-based, not class-based. It’s not considered a pure object-oriented programming language, although it can follow some object-oriented programming principles.

    The TypeScript Advantage

    TypeScript is a superset of JavaScript. If a developer knows JavaScript, there’s not much of a learning curve to take advantage of the features TypeScript offers that make up for many of JavaScript’s deficiencies—and it can offer additional benefits.

    For example, with JavaScript, variables can start as one property, and then change into an object or a string. These inconsistencies can generate problems that are difficult to resolve in large apps. TypeScript, on the other hand, analyzes the code and tries to determine proper variable types prior to runtime. Once a variable type is assigned, it stays unchanged. TypeScript’s compiler also helps shorten the QA and testing process in later stages of development.

    TypeScript also helps developers quickly figure out the purpose of a variable within the code. It can also suggest available properties in functions, classes or components. Being able to quickly look up a variable is important because it reduces the likelihood of calling the wrong function or accidentally skipping a variable declaration. Any reduction in bugs and errors reduces the time required for fixing those issues and, therefore, reduces overall development time. That gives developers more time to work on app logic and fix errors that can be detrimental to in-app performance and usability. According to a postmortem analysis by Airbnb, 38% of bugs they encountered were preventable with TypeScript after the company adopted it throughout the organization. 

    As a static language, TypeScript performs type checks upon compilation, flagging type errors and helping developers spot mistakes early on in development. Reducing errors when working with large codebases can save hours of development time.

    Clear and readable code is easy to maintain, even for newly onboarded developers. Because TypeScript calls for assigning types, the code instantly becomes easier to work with and understand. In essence, TypeScript code is self-documenting, allowing distributed teams to work much more efficiently. Teams (and individual developers) don’t have to spend inordinate amounts of time familiarizing themselves with a project.

    TypeScript’s integration with editors also makes it much easier to validate the code thanks to context-aware suggestions. TypeScript can determine what methods and properties can be assigned to specific objects, and these suggestions tend to increase developer productivity.

    TypeScript is widely used to automate the deployment of infrastructure and CI/CD pipelines for backend and web applications. Moreover, the client part (for example, when using Angular) and the backend can be written in the same language—TypeScript. This flexibility allows an engineer who knows one programming language to cover all parts of the system.

    Because TypeScript essentially transpiles to JavaScript, migrating existing code to TypeScript is easy and fast. It can typically be accomplished simply by running the compiler and adding typing where it’s not recognized by the language. There’s no need to make changes to the code.

    The benefits of TypeScript have been noticed by developers. TypeScript was used by 78% of the 2020 State of JS respondents, with 93% saying they would use it again. TypeScript continues to grow in popularity. It was voted the second most-loved programming language in the Stack Overflow 2020 Developer survey. 

    TypeScript & AWS: Better Together 

    There’s another compelling reason to consider TypeScript for large-scale app development projects. It’s fully supported by AWS, the leading cloud platform for modern app design and development as noted in Gartner’s Magic Quadrant for Cloud Infrastructure and Platform Services.

    The following services and tools have seamless integration out-of-the-box with TypeScript, enabling you to use this language for a vast number of tasks:

    • AWS CDK provides infrastructure-as-code (IaC) to automatically deploy the entire infrastructure in one click. You can also automate the creation of CI/CD pipelines for the future launch of specific jobs on demand.
    • AWS Lambda allows you to run computation tasks in serverless mode using automatic scaling and an efficient pricing scheme.
    • Amazon EC2, ECS and EKS can cover any of your tasks and provide a wide range of solutions for running apps written in TypeScript—from bare metal servers to complex clusters of hundreds of Docker containers.

    Optimize Your Application Development Projects

    All decisions made during an application development project can impact overall costs and time to market. That includes going with the right programming language and using the most appropriate cloud platform and resources. 

    When approaching an app dev project, a one-size-fits-all approach rarely works. Take the time to define your needs and priorities and select the best resources to deliver the best results.

  • Bridging the Developer Experience (DevX) Gap

    Bridging the Developer Experience (DevX) Gap

    They say our past experiences have an impact on how we view life and our general outlook. Routine behaviours and patterns become a program that we follow day in, day out. We stop using our minds to their fullest potential and become trapped in unquestioning, continual cycles of process and emotion.

    The same could be said of our experiences in the present—our worlds shaped by the environments around us. The people, practices, tools and culture. Only by challenging these accepted patterns can we start to think about changing our mindsets.

    DevOps is a mindset; a way of forming an agile relationship between development and operations teams to speed up delivery of software to support business operations and improve customer experience. By and large, it has been successful. Companies react to change more effectively; software is developed and deployed swiftly. It has become a necessity across most organizations.

    There are challenges, as we all know, however. The State of DevOps Report 2021 found that 83% of organizations are implementing DevOps practices, but most are still failing to scale adoption. It’s a situation that hasn’t changed for four years. Why? Among other things, the report states there are too many silos, not enough skilled people, a saturated market with too many tools—and a culture that prohibits scale.

    Given that the end goal of DevOps is to generate untrammelled innovation across an organization, getting the culture right is critical. Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

    Above all, it’s about creating the best possible developer experience (DevX) in which to thrive.

    The Developer Experience Gap

    Stephen O’Grady at Red Monk, the developer-focused analyst firm, originally wrote about a DevX (developer experience) gap in this post back in October 2020.

    Stephen likened the experience you get from an iPhone to the expectations of developers. The iPhone’s closed SDK created an environment that allows all developers to work in a consistent way. Functions are tightly integrated so that, for example, it would be easy to ensure the music volume lowers when you receive a call. A basic function, but one that we expect to work seamlessly with any app we install.

    Since then, developers have been served a vast array of tools and services with more and more software arriving on a daily basis. The challenge is that, where the phone and music player teams were controlled in a way that would make them work well together, modern development infrastructure doesn’t have that capability. In most cases, the toolchain is a “patchwork quilt” of products and services from different suppliers. And it is up to developers to build and maintain that quilt.

    This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

    In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

    Delivering the DevX Factor

    Attracting the best people is about showing that the experience they will have in your organization is both rewarding and liberating, so expecting developers to spend the bulk of their time not developing is clearly not an optimal experience. Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

    Where to start? Well, contrary to popular belief, you don’t need an army of DevOps engineers to reach your goals. Instead, you need to empower your existing teams to reach their full DevOps potential, supporting their progress with the right tools and training for their experience and role.

    As with any work culture (remote or hybrid), the importance of knowing where to find what you need and how to collaborate with other teams has never been so important. Tooling is a good place to start. DevX is affected by the tools they use, so organizing them in a way that helps with the culture is a step forward. In a multi-cloud, multi-vendor environment, there isn’t going to be one tool that does it all so the key is to allow teams to use the tools they love and automate as much as possible to remove the repetitive tasks.

    Automation is also a critical element in the race to reduce time-to-market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on developers. Having access to testing automation in a consistent way will improve the overall experience for DevOps teams.

    And finally, think about starting your DevX journey by using a self-service platform, where information, tooling and automation can be centralized and made available to developers on demand. For overworked specialists, access to a platform that connects to any tool and creates an on demand environment that automates much of the repetitive work will create more time for them to do what they were originally employed to do: Develop.

  • Will Automation Fill Gaps Left by the ‘Great Resignation’?

    Will Automation Fill Gaps Left by the ‘Great Resignation’?

    Between burnout, job-hopping and the ongoing pandemic, labor shortages will surely get worse before they get better, and automation is increasingly sought after as a way to mitigate the ripple effects of understaffed IT departments.

    For DevOps, automation has several benefits, from freeing up employees to work on more constructive tasks to minimizing software bugs and technical debt.

    However, starting off slow and learning how automation will help address staff shortages without complicating processes is a critical factor.

    “There’s still a lot of teams that are struggling with far too many manual or repetitive tasks,” said Rich Lane, chief strategy officer at Netenrich, a digital IT and security operations company. “Obviously, trying to do your day job of delivering features and functionality into the wild can be challenging with the speed that business needs demand.”

    Lane, a former senior research analyst at Forrester Research, pointed out that slowing down in the present to do foundational work that can lead to higher levels of automation in the future can be hard to sell to digital services stakeholders.

    “And yet, without doing so, it becomes increasingly difficult to meet commitments in the event a team becomes shorthanded or delivery requirements increase,” he said.

    Generalist or Specialist?

    Cody Michaels, application security consultant at nVisium, said when it comes to hiring people for a DevOps environment, you have one of two options: You can hire someone with a wide range of knowledge that spans the entire process or you can hire someone with expertise in one core area like programming or deployment.

    “At an individual level, a generalist will be better than an expert, however, a team of experts will outperform a team of generalists,” he said. “Not only can automation fill in gaps between an expert’s area of influence, but it can also serve as a permanent fixture on the team. As a result, the turnover rate won’t affect any automation so long as it’s implemented properly.”

    From Lane’s perspective, the main areas DevOps teams should be looking to automate are continuous integration and continuous delivery (CI/CD), IaC and AIOps-enabled incident management platforms.

    “By taking the manual nature of day-to-day work off of DevOps engineers’ plates, they are freed to focus on digital transformation,” he said. “The number-one stumbling block is not starting with process.”

    Lane noted unless you understand all the steps in a procedure that you’re trying to automate, it is very difficult to maximize the power of automation tools.

    “Much of the process that is still adhered to today is outdated for the digital age,” he said. “Spend the time up front to map out what you hope to achieve with an automation project, what all the touchpoints are and how one can measure the quality of automation when it’s implemented.”

    Michaels added that while the internet is flooded by companies shouting they have the “best” tools, that proclamation of “best” is going to be determined by budget and known languages.

    “The top tools that I would recommend are Jenkins, Docker, Git and Jira, since these four play very well together with regard to automation,” he said.

    Git, for example, has hooks that can trigger upon performing certain actions, like freshly submitted code, while Jenkins has automation as its middle name and it’s used in building, testing and deploying, which in turn facilitates CI/CD.

    Meanwhile, Docker provides virtualization of operating systems and running applications in a secure manner in conjunction with containers.

    “Lastly, Jira is one most don’t think about, but the platform has a lot of macros and filtering functionality that can update the work process automatically from events like code passing a test before it’s deployed, for instance,” he said.

    Michaels said a couple of core considerations organizations need to make when approaching the idea of automation and AI are time as well as safety nets in place.

    “Automation will take time to set up before you can benefit from it, but in the case of smaller teams, it won’t be too time-consuming to configure it all in one fell swoop,” he said. “But if you’re working with a lot of technical debt, unfortunately, it’s going to be payback time. If this is the case, my best advice would be to start small and not overhaul everything at once.”

    Minor Automation Improvements Have Major Benefits

    He said he thinks incremental improvement will be the best route for most organizations, and that even minor improvements will compound far faster than waiting a year to see if a redesign will work for you.

    “As I mentioned previously, it’s imperative to have safety nets in place,” Michaels said. “Make sure you have a contingency plan if something goes wrong in the process to recover back to a working state. However, strictly speaking, everyone should make it a practice to have a recovery plan in their software development life cycle (SDLC).”

    As the DevOps world moves into 2022, organizations choosing to embrace automation could find themselves in a win-win situation—for both developers and operations.

    “The more automation takes over the ‘housekeeping’ items of the process, the more time will be freed up to improve the process as a whole,” Michaels said. “As a result, taking time to go back and clean up technical debt can now be set aside between sprints and maintenance.”

    He pointed out that senior roles can tackle optimizing the architecture, which will ensure fewer bugs and a healthier work-life balance for all: Just imagine a world where developers can focus on perfecting their craft—instead of waiting hours or days for server reboots or disrupting their flow to update a ticket status.

    “It really comes down to the fact that organizations can no longer make automation an afterthought,” Lane added.

    He pointed out that given the difficulties in recruiting and retaining staff today, DevOps leaders must make their teams as efficient as possible—and automation can help achieve that goal.

    “The number-one way to achieve this is applying as much intelligent automation throughout the IT environment as possible so that the highly-skilled engineers can focus on transforming the business,” Lane said.

  • Fugue Marries Compliance-as-Code Tool to AWS Well-Architected Framework

    Fugue Marries Compliance-as-Code Tool to AWS Well-Architected Framework

    Fugue has infused the best practices defined by Amazon Web Services (AWS) within its software-as-a-service (SaaS) offering for provisioning infrastructure using its infrastructure-as-code (IaC) platform.

    Fugue CEO Josh Stella said that IT teams can now evaluate templates for provisioning AWS infrastructure that were created using AWS CloudFormation or Terraform tools to ensure they comply with the AWS Well-Architected Framework.

    The AWS Well-Architected Framework spans five pillars that AWS has defined for designing and operating reliable, secure, efficient and cost-effective systems in the cloud. AWS has defined a set of best practices for each pillar and rewards organizations for following those by making available additional cloud credits. The goal is to improve overall cloud security by providing guidance that ultimately reduces the number of misconfigurations so that cybercriminals can’t discover and exploit them.

    The Fugue platform complements that effort because it is based on Open Policy Agent (OPA), a general-purpose engine for managing compliance-as-code that is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). Fugue extended OPA by creating Regula, an open source tool that evaluates IaC files for potential security and compliance violations. Fugue then created a SaaS platform that makes extensive use of the AWS Lambda serverless computing platform to make it easier to enforce compliance policies.

    Those policies include turnkey coverage for specifications such as SOC 2, NIST 800-53, GDPR, PCI, HIPAA, ISO 27001, CSA CCM, CIS Controls, CIS Docker and CIS Foundations Benchmarks for AWS, Microsoft Azure, Google Cloud and Kubernetes.

    Stella said Fugue has now incorporated the technical aspects of the AWS Well-Architected Framework. However, it’s still up to each IT team to navigate the cultural aspects of the shared responsibility model of compliance and security that cloud service providers like AWS follow.

    Unfortunately, developers that employ IaC tools to provision cloud infrastructure often make some faulty assumptions about the level of security maintained by the cloud service provider. The result is often a raft of security and compliance issues that arise mainly because most developers don’t have a lot of domain knowledge expertise in either area.

    It’s not clear how many organizations have adopted the AWS Well-Architected Framework, but as various tools make it easier to implement these best practices defined by AWS the more secure and efficient cloud computing environments should become. In fact, in many cases, those tools are being embedded within a larger set of DevSecOps best practices that are being implemented across multiple clouds.

    Stella said he doubted there will ever be any standardization when it comes to security and compliance frameworks that could be applied to multiple clouds; however, it’s clear that cloud service providers are at least making available frameworks that borrow concepts from one another.

    Regardless of the approach, the overall state of cloud security and compliance will continue to improve as more guardrails are automatically implemented. The issue then becomes not only finding a way to ensure that cloud infrastructure is secure when deployed and also determining how much of the infrastructure being relied on today is less secure than it should be.

  • FinConDX: Leveraging DevOps in FinTech

    FinConDX: Leveraging DevOps in FinTech

    The FinTech industry has experienced remarkable growth during the last couple of years as consumers increasingly turn to online shopping and contactless payments. Financial services organizations are adopting DevOps practices to enable faster software releases, improve quality and fulfill customer expectations. On Dec. 9, financial services and tech leaders will come together at FinConDX Virtual Event to discuss the latest and most effective DevOps, DevSecOps and digital transformation practices and tools you need to thrive in the FinTech industry.

    The agenda for FinConDX features a mix of topics, including continuous security and continuous compliance best practices, value stream management, secure development in highly-regulated industries, source code security in financial services, threat detection, incident response, software supply chain attacks, cloud security, emerging technologies and modernization tools.

    FinConDX features a stellar lineup of industry experts, including:

    • Ravi Lachhman, field CTO at Shipa
    • Simon Maple, field CTO at Snyk
    • Dan “Pop” Papandrea, director, Opensource Community and Ecosystem at Sysdig
    • Ravi Yadalam, head of product for cloud optimization at Harness
    • Eric Carter, director of product marketing at Sysdig
    • Maurice Evans, director of product management at BluBracket
    • Jeff Keyes, VP of product marketing and strategy at Plutora
    • Ronen Slavin, CTO and co-founder at Cycode
    • Andrew Fife, VP of marketing at Cycode
    • Edwin Kwan, application and software security, security advisory at Tyro Payments
    • Sanjeev Sharma, SVP, head of Platform Engineering at Trust Bank
    • Colin Wynd, head of Real Time Payments Technology at The Clearing House
    • Mitch Ashley, CTO, principal at Techstrong Group, Techstrong Research

    The virtual environment features five session tracks, live chats, raffles and prices, entertainment and an exhibit hall lined with booths showcasing the latest solutions from leading DevOps companies. In the exhibit hall, attendees will have access to downloadable resources provided by our partner sponsors.

    Registered attendees will also receive a link to access the virtual environment on-demand once the live event is over.

    To see the full agenda and to register, please visit the FinConDX website.

  • A Pro Football Approach to Agile Vs. DevOps

    A Pro Football Approach to Agile Vs. DevOps

    Enterprises and professional football teams have a lot in common. The pressures of being more agile, more resilient while ensuring performance is felt both on and off the field. For CIOs, surviving and thriving requires a serious focus on operations tied to business mandates and growth.

    I am frequently asked questions around infrastructure and operations (I&O) with organizations looking to solve ITOps, DevOps and DevSecOps challenges.

    • How do we shift from legacy ITOps models to transformative digital operations?
    • How do we align process, people and tools for closer integration, consolidation and correlation?
    • How are we structured as teams across functions—ITOps, DevOps, SecOps?
    • How do we transform to analytics-driven operations at speed and efficiency?

    Historically, Agile and DevOps teams face off on the IT playing field as adversaries; both sides want to advance their plans, execute plays and reach the end zone. Disconnects happen when teams are not aligned, goals are not defined and resources are constrained.

    To effectively deliver digital services, teams must focus on the essentials of clear communication, unified culture and measures to ensure resiliency, performance and availability if they are to be effective.

    Traditional I&O teams often operate independently, and knowledge is not shared nor available to cross-functional teams. Attempts to respond and resolve critical incidents can take longer. With DevOps or even DevSecOps, the ideal is for groups to align across functions by breaking down silos of tooling and responsibility.

    In a hybrid ops environment, a lack of integration and coordination between DevOps roles can easily misalign efforts and priorities. Whether it’s hybrid in terms of IT environment or hybrid in support model, there are unique challenges that must be addressed. Not being able to huddle around the same data sets while troubleshooting incidents poses a huge challenge when implementing proper analytics comes into play. Legacy IT operations management (ITOM) tools simply cannot support DevOps’ use of cloud-native services nor support remote IT teams working globally.

    For successful DevOps and traditional Agile teams to coexist and be successful, IT leaders need to change existing mindsets and implement new practices in order to scale.

    • DevOps and ITOps groups have to feel supported by the entire IT organization.

    Often DevOps starts as an experiment with a small group of people working on one application. Everyone in IT, from the leaders to IT workers, needs to understand what the end goals are for integrating new methodologies. Deep realization sets in when DevOps finishes a project and pushes to production which is still supported in traditional ITOps models. It becomes obvious that operations needs to adapt to frequent change.

    • Plan and implement DevOps practices to avoid disruptions.

    With legacy systems still in practice for delivering digital services, DevOps teams cannot disrupt critical day-to-day operations by driving new support models without taking into account migration considerations. Instead, teams will need to work in a hybrid model using application development delivery methods.

    • Collaboration and planning tools are essential.

    The use of collaboration and planning tools alongside automation capabilities is essential in hybrid organizations. Start by automating alerts to generate tickets for the appropriate team(s) to handle versus having Level 1 support process all alerts independently.

    • Build or buy scalable data analysis systems.

    These systems will aggregate and correlate data across infrastructure and digital/cloud-native technologies to deliver contextual insights to problems and provide corrective steps to resolve them.

    Scaling and modernizing operations and creating agile practices is an ongoing process that needs constant planning, testing and adapting. Streamlining DevOps and ITOps processes using automation starts the process as teams begin to work together versus working in traditional silos.

    For winning football franchises, dynasties weren’t built in a single season; the same is true for your digital ops transformation. It takes challenging the status quo—taking a hard look at the deeply embedded ways ITOps has always been done—and reimagining the whole process focused on data-driven digital operations.

  • WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Working from home is de rigueur, JEDI redux, and more about Nvidia/Arm.

    Survey Says: Devs Stay Out of Office

    First up this week: GitHub’s annual survey of developers has some fascinating data on the workplace (ahem) “new normal.” The pandemic has radically changed devs’ expectations of where they can do their jobs.

    Analysis: WFH is SOP

    As with other roles, Dev people want to continue to work from home. But does this pose a threat to your DevOps culture? Make sure you can do Ops with equal flexibility.

    Paul Krill: Dev productivity is back to pre-pandemic levels

    GitHub’s “2021 State of the Octoverse” research … sees signs that work rhythm is returning to pre-pandemic levels. GitHub also found that 46 percent of developers who worked co-located with teammates now expect to work fully remotely or in a hybrid environment.
    …
    Based on data culled from more than four million repositories and surveys of more than 12,000 developers … JavaScript and Python remain the top languages, followed by Java and TypeScript. [And] GitHub found that development team performance can increase as much as 87 percent when reusing code and as much as 43 percent when using … CI/CD.


    Zeroing in on the WFH angle, it’s Richard Speed:

    Respondents who were in the office either full or part-time dropped from 42 percent before the pandemic to a mere 10.7 percent now. … That’s a lot of empty desks.
    …
    Fans of the ctrl-c, ctrl-v combo will be delighted to note that GitHub found that when code reuse was made “frictionless” at work, developer’s performance increased by up to 87 percent. … It’s all splendid stuff.


    But beware of statistical fallacies, thinks Henrik Ingo—@h_ingo:

    #WorkFromHome may have been more common than anyone realized. [But] is the population of GitHub users/respondents somehow skewed toward pioneers/early adopters? … This might be a case of correlation is not causation.

    Defense Dept. Orders New Clouds

    The DoD issued its latest cloud contract opportunity notice, with the snappy title of “Joint Warfighting Cloud Capability” (JWCC). Reading between the lines of the notice, it all sounds very DevOps-cum-Agile.

    The Pentagon has backed away from its previous insistence on a single supplier, and now wants at least two cloud providers.

    Analysis: JEDI redux, because AWS wants a do-over

    JWCC is the follow-on from the aborted JEDI procurement. Amazon Web Services was “disappointed” to have been passed over in favor of Microsoft. Now it appears the DoD wants them to share.

    What can you learn from such a multi-vendor DevOps strategy?

    Jordan Novet: Pentagon asks Amazon, Google, Microsoft and Oracle for bids

    Amazon and Microsoft were the finalists for a single Joint Enterprise Defense Infrastructure. … Microsoft won it in 2019, Amazon filed a protest and the Pentagon canceled the contract in July.
    …
    The new effort [is] known as Joint Warfighting Cloud Capability. … JWCC differs from JEDI because it allows the Pentagon to rely on multiple cloud providers.
    …
    The U.S. General Services Administration … said only two U.S. cloud infrastructure providers, Amazon and Microsoft, appear able to comply with all of the Pentagon’s requirements. … The value of the new contracts is not known, but the Defense Department estimates it could run into the multiple billions of dollars.


    In summary, heed this Anonymous Coward:

    Competing suppliers will try harder than one non-competing supplier. The DoD has had a lot of problems with One-Ring-to-rule-them-all systems like the F-35. … JEDI would have been the same.
    …
    Smaller steps with upgrades while testing/using offers better returns. Done right they can get a better deal by making the companies compete against each other in making sure the products are actually useful.


    But look carefully at the DoD contract opportunity, says bustinbrains:

    They’ll all get contracts. Then DoD will simply use the one that they actually like the best. No one can complain because it’s open-ended with no guarantees.

    Arm/Nvidia Deal on FTC’s Radar

    Last week, we talked about Nvidia’s goal to acquire Arm Ltd from SoftBank, and the regulatory challenges it poses—notably in the UK, home of the chip architect. After we went to press, the other shoe dropped.

    Analysis: Just Give Up Already

    As we said last week, Nvidia can’t be allowed to do this. Not only are ARM chips found in 99% of smartphones, but they’re an increasing fixture in the datacenter—especially places that value “performance per Watt.”

    Richard Waters: What’s next for the tumultuous takeover of Arm?

    Nvidia’s acquisition of UK chip design company Arm from SoftBank has provoked serious opposition on both sides of the Atlantic. … The US Federal Trade Commission had its own worries. China, meanwhile, is waiting in the wings.
    …
    The deal has shone a spotlight on the unique position Arm plays in the chip industry. [Nvidia] offered a guarantee that it won’t block any other companies from licensing Arm’s designs. The offer has fallen on deaf ears, with both the EU and UK ruling it inadequate. … Post-Brexit politics have also come into play.
    …
    At what point might Nvidia and SoftBank call it a day? … A stock market listing [is] the most likely alternative, with the UK a favoured venue.


    How’s it viewed from the inside? Here’s a hint from fivemack:

    I was at ARM when Softbank bought them; it came as a surprise to everybody, because we were absolutely confident that we were unbuyable because anyone interested in us would want to use differential licensing as a weapon against their competitors, and we … were confident that regulators wouldn’t accept that.
    …
    Lots of people went home with a year’s pay check in free money. And not a few people … went home with a decade’s pay check in free money.


    More and more DevOps workloads are running on ARM silicon. Here’s Biophoton:

    The low power expertise of ARM has to be an advantage in the data centre (DC) market. … Plus Linux is available on ARM so architectural lock-in of Intel could be eroded in the DC market.

    The Moral of the Story: You are known by the company you keep


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Lukas Mann (via Unsplash)

  • Top 10 DevOps Things to Be Thankful for in 2021

    Top 10 DevOps Things to Be Thankful for in 2021

    Thanksgiving has been observed in the U.S. since 1861 and was officially designated as an official holiday in 1863 by president Lincoln. Of course, the tradition itself traces its lineage to the early days of the Pilgrims.

    This past year, of course, has been one of recovery from a pandemic that caused the deaths of millions of people around the world. Vaccines have saved the lives of countless more, so there is much to be thankful for despite all our recent trials and tribulations. In that spirit, there are more than a few things for DevOps professionals, in particular, to be thankful for this year starting with:

    Digital business transformation: Organizations of all sizes have had to adjust their business models because of both major changes in buyer behavior and an ongoing supply chain crisis. DevOps teams are at the core of any major digital business transformation initiative, so the demand for DevOps expertise continues to outstrip the available supply. Going forward, it’s been predicted we’ll see more digital transformation in the next 10 years than in all the last 40 years combined. The vast majority of those initiatives would never see the light of day if it were not for the expertise of developers and engineers working hand-in-hand to build and deploy applications faster than ever.

    Low-code platforms: As the demand for applications to drive digital workflows spiked in the wake of the pandemic, professional developers relied more on low-code platforms to decrease the time required to build an application. While many complex applications will still be built using procedural code, it’s clear not nearly as many applications could have been deployed without relying on low-code platforms to build them. It remains to be seen how many of the next generations of low-code applications will be built by so-called citizen developers that may soon be flooding DevOps pipelines with application code.

    Microservices: As an architecture for building applications the core concept of employing loosely coupled services together to construct an application goes all the way back to when service-oriented applications (SOA) were expected to be the next big thing in the 1990s. Microservices have, of course, been around for several years themselves. However, with the rise of containers as a software artifact for building microservices, it’s only now becoming apparent that building an application constructed using microservices not only takes less time but is easier to maintain and also more resilient.

    Observability: As a concept, observability traces its lineage to linear dynamic systems. Observability in its most basic form measures how well the internal states of a system can be inferred based on knowledge of its external outputs. In the past year, a wide range of IT vendors introduced various types of observability platforms. These make it easier for DevOps teams to query machine data in a way that enables them to proactively discover the root cause of issues before they cause further disruption. That’s a major advance over monitoring platforms that typically only provide predefined metrics to identify when a specific platform or application is performing within expectations.

    Biden’s executive order: In the wake of a pernicious attack against IT service management software from SolarWinds, the Biden administration published a sweeping executive order that requires federal agencies to implement a wide range of security best practices. Foremost among them is guidance concerning the security of software supply chains; which resulted in many organizations reviewing their entire software supply chain to make sure similar breaches will not occur.

    DevSecOps: As an extension of any DevOps best practice, DevSecOps generally describes an overall shift left in terms of making developers more responsible for application security. While still in its relative infancy, DevSecOps is starting to gain traction as DevOps and cybersecurity teams look to bridge a cultural divide that is as wide as any in IT. The ultimate goal is to deliver more secure applications without reducing the speed at which they are being built and deployed.

    GitOps: At its core, GitOps is an operational framework that takes DevOps best practices used to automate application development and extends them to infrastructure. The basic idea is that the configuration software created to manage infrastructure-as-code is just another software artifact to be stored in a Git repository. The approach provides a means for IT teams to achieve a continuous delivery goal that, more than a decade after DevOps best practices were defined, remains elusive. It’s still early days as far as GitOps best practices are concerned, but this has been the year when GitOps become part of the mainstream DevOps conversation.

    Kubernetes: Simultaneously one the most powerful and most complex IT platforms ever to come down the proverbial enterprise IT pike, Kubernetes has emerged as a de facto standard for building and deploying container applications that can more efficiently scale up and down as required to consume IT infrastructure. The challenge (and the opportunity) now is to make Kubernetes much more accessible to mere mortal IT administrators that typically don’t have the programming skills of a site reliability engineer (SRE) and which are both hard to find and retain.

    GraphQL: Employed as a query language for application programming interfaces (APIs), GraphQL provides a more efficient means of accessing data than the REST APIs that have been employed by developers in the past. Originally developed by Facebook, GraphQL adoption is still in its infancy but it’s clear APIs based on GrapQL will one day be as plentiful as REST APIs. That’s especially critical for microservices-based applications that rely on APIs to access data across a highly distributed computing environment that requires a more efficient means for transferring data.

    Venture and Wall Street capital investments: Investment firms are helping fuel DevOps advances as they continue to make capital available for companies vying for their share of a market that is expected to see compound annual growth rates of 24.7% through 2026. There will, of course, eventually be a wave of consolidation as merger and acquisition activity inevitably ensues. In the meantime, however, there is a wide range of DevOps technologies that might not otherwise be as broadly adopted if it were not for all the cash being poured into DevOps companies.

    The most important thing, of course, is that so many DevOps professionals are still here to build and deploy applications. It’s been a trying year for all concerned; however, as the pandemic crisis continues to recede, we can all be thankful for the opportunities that lie ahead.

  • Rethinking Programmer Education for Today’s Coders

    Rethinking Programmer Education for Today’s Coders

    The proliferation of low-code and no-code applications are changing the landscape for software. In the past decade, growth in these areas has empowered employees to generate solutions at the speed of a digital world, regardless of their technical background.

    This raises several questions: What kind of programmers do businesses really need? Should they still rely on programmers formally trained at four-year universities—what you might call “white-collar” programmers? Or, instead, are blue-collar programmers with self-taught skills or those who learned from a bootcamp more valuable? What will get organizations the right mix of programming skills?

    The short answer is that all programmers can be of great value. In general, blue-collar programmers, after all, connect things within the computing environment, while white-collar programmers create the things that are connected. The essence of low-code is that it allows more people to connect things and use their creativity to become more productive. But it doesn’t eliminate the need for professional programming and tools at its foundation.

    At their core, low-code and no-code are about democratization. They allow people without technical skills to work creatively in ways that essentially make everyone a programmer. A parallel from an earlier computing generation is the Excel spreadsheet, which lets people with no programming background perform computational tasks and eventually work their way up from simple formatting to full-fledged programming. But at some point, polished programming skills are still necessary, no matter how easy no-code or low-code can make some of those elements.

    In the breakneck pace of cloud-based computing environments with new services constantly being developed and deployed to the edge, it’s worth considering the distinctions between the white- and blue-collar programmers and what kinds of education are appropriate for each.

    Four-Year Colleges Vs. Boot Camps

    A career as a programmer can seem intimidating for onlookers. This is particularly true when these jobs involve complex languages such as C++ and Java, which are often used in large projects that can take years to develop and involve millions of lines of code. Some of that is still true, but the evolution of programming over the years toward languages that require less code, such as Python, and to domain-specific languages (DSLs), has also started to lower the barriers to entry for programming.

    It’s true that you’ve never needed a four-year computer science degree to be a programmer. In fact, many that have dropped out of college—or never attended at all—have made significant contributions to the industry. However, universities do provide a foundation in theory and algorithms that have always served programmers well and enable them to branch out into new areas, such as artificial intelligence or other disciplines, such as bioinformatics. Coding bootcamps, for their part, can provide intensive training on DSLs or frameworks like Rails or React.js that can benefit companies’ plans, giving blue-collar programmers the practical skills that white-collar programmers may not have. They also attract career-changing attendees with four-year degrees in other subjects, including the humanities and the sciences, which brings badly needed new ways of thinking into the profession.

    While each method is valid, both four-year institutions and bootcamps also have their shortcomings. Universities delve deep into software development theory but often don’t emphasize critical aspects of doing the job, such as teamwork, testing and agile processes. Nor do they focus much on core areas of businesses today, like cloud computing. Boot camps, by targeting specific areas and emerging technologies and languages, can help people get internships or entry-level jobs, but don’t provide a broader theoretical knowledge of programming. And they can be hit-or-miss, with some of them using sketchy practices for payments and job placement.

    The inherent weaknesses in both white- and blue-collar training can be addressed through apprenticeships and internships, but only to a point. The question remains: Who will train low-code programmers on modern development and coding practices? A lot of companies throw around terms like Agile and CI/CD, but they’re often just new labels on old, inefficient practices. Companies will need white-collar programmers to bring blue-collar programmers up to speed.

    Programming for the Masses

    No-code software is a great enabler, allowing people with no formal education or experience to become proficient in a programming environment. On the other hand, for people who do have formal training—whether a formal education or boot camp experience—low-code simplifies their work, leaving time to focus on more complex projects. But programmer or not, users of no-code and low-code solutions need to understand more than just deployment and testing if they want their software to be reliable and useful.

    Professional developers can make a difference by creating and maintaining the pipelines used to build, test, archive and deploy low-code software; they will need to build new tools to accommodate low-code frameworks. And while familiarizing themselves with current development techniques, they could become the teachers of essential computing practices that don’t involve coding.

    A cooperative, productive relationship between white-collar and blue-collar programmers is essential to moving forward with software development, as it will allow both to continue acquiring new skills and experience outside of low-code, which is only a product of programming, no matter how ubiquitous it may be.

    Making the Connection

    Today, we’re entering a business world where practically everyone will need to code, making low-code and no-code frameworks necessary, especially for users without formal training. However, the importance of professional programmers will remain, too.

    We’re likely to see a proliferation of DSLs created to solve specific problems, which will eventually evolve toward general-purpose programming languages. Programmers will need to build web frameworks, cloud capabilities and more, including everything from web widgets to the high-level tools that let users work. That may be the only way we can begin to meet the demand for more people who can program as more devices come online, more connections are made and the world becomes increasingly reliant on automation.