devopsy.kinsta.cloud

Category: DevOps Culture

Empowering Developers Through Lean Code
Digital transformation is widely understood as a critical component for increasing user adoption, fueling workplace productivity and innovation, and driving business growth. Software has become increasingly important across countless industries, teams, and functionalities, and as a result, companies are beginning to understand that being an industry leader and gaining competitive advantages starts with software development.

Easier said than done. Modern software apps are a complex orchestration of infrastructure, deployment pipelines, notifications, user experience, data filtering and processing, and error handling. A good engineering team will be able to account for each of these items and integrate them into a larger, comprehensive infrastructure.

So what happens when you don’t have a solid, in-house team guiding your software maintenance and development? Consider a lean code development platform; a developer service that pares down the explicit requirements of standard functions, interactions, errors and software infrastructure into implicit scripts, templates, configurations and API requests. Using a lean code solution will give your team the power to build higher-quality features more quickly than they otherwise would on their own.

There are several ways that lean code platforms can simplify processes for developers. Primarily, these platforms turn explicit requirements into implicit interactions, eliminating the need for developers to pull elaborate infrastructure to solve complex problems. Lean code also gives developers the freedom to customize everything to fit where it is needed, while limiting the amount of code necessary to do so. Lastly, lean code platforms provide tools that assist developers at all levels of the software stack, significantly increasing productivity while cutting down on time and workload.

How Does it Differ from Low-Code?

While many people might be unfamiliar with the term “low-code,” they’d probably be surprised to learn that they use it all the time. Low-code describes platforms that require minimal code in order to build applications and processes.

Essentially, these programs enable users with little to no coding or software development experience to create and use applications. The idea of low-code is to introduce audiences to intermediate level software development concepts such as object-oriented programming, interface design, conditional logic and code syntax.

However, no matter how helpful these low-code approaches might be, many users still run into the problem of wanting more customization than the low-code system is designed to give. In fact, many users become frustrated with the term “customization” because it’s viewed as the enemy, indicating a need for more advanced software development services than the consumer is able to provide.

Lean code platforms, on the other hand, are designed to specifically meet developers’ needs at all stages of the software development life cycle. In essence, lean-code prioritizes simplicity, efficiency, flexibility and accessibility with the goal of making software development accessible on a larger scale.

Instead of encouraging you to reduce your development team, lean code platforms allow users to expand development through exploring new avenues and abstracting away the explicit requirements of traditional software development.

What Does Lean Code Have to do With Productivity Infrastructure?

Many forward-thinking companies have gone beyond simply building technical solutions to specific development problems. Instead, they’ve taken the advancement of lean code platforms to a new level by providing fixes that meet developers at the central stages of the integration process.

Because lean code offers such integrated solutions to developer challenges, the approach is increasingly becoming the norm across the bulk of the productivity infrastructure category — an emerging market category that combines elements of cloud communications services, API platforms, low-code development tools, business process automation and AI software development kits.

If you’re looking to implement a lean-code platform, consider the following features:
- Intelligence: By making it easy to pull information from unstructured data sources and flip it into more meaningful material, machine learning (ML) replaces the manual effort to build, implement and maintain models.
- Automation: Workflows, triggers, templates and notifications can be abstracted away for common use cases.
- Security: When handling user data, security is a top priority. From protecting health records to pet names, data security is crucial.
- Connectivity: The ability to connect to a relevant data source can make or break an infrastructure.
- User experience: User interfaces should follow expected conventions for whichever task the user is trying to accomplish. Maintaining a successful user experience requires constant evaluation.
How will Lean Code Become Market-Leading Software?

Lean code development platforms have emerged as market-leading software development solutions in three major areas:
- Productivity Infrastructure: More companies have pivoted to providing full-stack development services that assist developers in building out native communications, search and indexing, scheduling and financial experiences.
- Software development and deployment workflows: Continuous integration/ continuous deployment (CI/CD) pair down complex build and deployment pipelines to basic configuration files.
- Infrastructure deployment: Infrastructure as a service (IaaS) products assist in deploying scalable web services via API requests and simple configurations.
Where are lean code development platforms headed?

It’s safe to assume that, given their ability to provide efficient and effective infrastructure to development teams, lean code has a bright future ahead. The number of developers in the space is only growing. A Slash Data survey from 2019 estimated there to be just under 19 million active developers across the globe and expected the number to grow to 45 million by 2030.

As the market for software development rapidly expands, it would make sense to assume that the need for a platform that solves problems across the entire software ecosystem would, too. Lean code development platforms are emerging as a top choice for companies that want to build out a leading software platform into the future.
May 7, 2021
DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More
We are excited to announce the return of DevOps Connect: DevSecOps Virtual Summit on May 19, as part of the RSA Conference 2021. This year, internationally recognized speakers will take a deep dive into “Securing the Cloud Native World.”

DevOps Connect is a full-day event, featuring four different content tracks, with more than 50 speakers, including keynote presentations, demos, insight talks and featured sessions.

The agenda features a mix of topics, including cloud security, CI/CD, Kubernetes, GitOps, AppSec, security risks, shift left, open source, case studies covering DevSecOps and more. Attendees will learn how the finance, manufacturing, healthcare and hospitality industries are securing their cloud environments, and how to better secure and monitor their systems.

DevOps Connect 2021 Lineup

DevOps Connect 2021 features an exceptional lineup of the most prominent and respected security and DevOps leaders, including:
- Featured keynote speaker: Christopher Krebs, former director of the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), and co-founder of Krebs Stamos Group LLC
- Chenxi Wang, founder and general partner at Rain Capital
- Allan Friedman, director of cybersecurity initiatives at National Telecommunications and Information Administration in the U.S. Department of Commerce
- John Willis, senior director of Global Transformation Office at Red Hat
- Cyndi Gula, managing partner at Gula Tech Adventures
- Alessandro Vozza, principal software engineer at Microsoft
- Caroline Wong, CSO at Cobalt
- Thomas Krane, principal at Insight Partners
- Charles J. Kolodgy, principal at Security Mindsets LLC and analyst at Accelerated Strategies Group
- Nisha Kumar, open source engineer at VMware
- Mike Rothman, president at DisruptOps
- Dave Howell, VP at ZeroNorth
- Maciej Mensfeld, senior product manager at WhiteSource
- Matt Wilson, senior product manager at GitLab
- Erkang Zheng, founder and CEO at JupiterOne
- Philippe Humeau, CEO at CrowdSec
- Jennifer Czaplewski, director of product security at Target
- Al Sargent, senior director of product at InfluxData
Former CISA director Christopher Krebs, our featured keynote speaker, will be answering questions from the audience during a live Q&A.

Workshop Friday

We are also hosting Workshop Friday, as we wrap up the RSAC 2021, offering live workshops designed to be as interactive and hands-on as possible with experts from Google, JupiterOne, Sysdig and Sonatype. These workshops provide professional guidance and training on a variety of topics, including Site Reliability Engineering (SRE), AWS cloud security and protecting against supply chain attacks. On May 21, attendees will have the opportunity to interact with the experts, share their process, get immediate feedback and personal assistance. Each workshop will be live-streamed through our online platform at no cost to attendees. We have limited spots available. Seats are reserved on a first-come, first-served basis. To save your spot, visit the Workshop Friday website.

A Unique Virtual Environment and a Few Surprises

The virtual environment features an auditorium with different tracks where attendees can watch the sessions by industry experts. There will be an expo hall lined with booths featuring interactive chats and downloadable resources. The expo hall will be open throughout the event, giving attendees the opportunity to chat with sponsors, including GitLab, Prisma Cloud by Palo Alto Networks, Sonatype, WhiteSource, Sysdig, JupiterOne, Snyk and more.

We have a few surprises planned to make this year’s DevOps Connect extra special. Take a break between presentations, grab your yoga mat and enjoy a Pilates class by a certified instructor, dance to the music of our featured DJ and check out how to make a delicious cloud drink by a professional mixologist. You can also participate in a raffle to win a copy of “You Can Stop Stupid” by Ira Winkler, author and president at Secure Mentem, and a copy of “Security Yearbook 2020” by Richard Stiennon, industry analyst at IT-Harvest.

DevOps Connect 2021 offers the best of a physical environment in a virtual context combined with the advantages and convenience that a virtual environment offers.

Registered attendees will receive a link to access the virtual environment on-demand. To check out the full agenda and to register, visit the DevOps Connect website.
May 6, 2021
Lessons in User Engagement From Game Development

Quarantine measures forced most of the world to stay physically distant — a shift that has forever changed consumer behaviors, and especially how humans interact and spend their free time. A clear change over the past year was the rapid boom of gaming, which saw a massive increase in both console and mobile games — estimated to be as much as 50%. With this sudden increase in new players, how can developers keep gaming experience fresh and exciting? What can game developers do to keep players coming back after they hit ‘Close’? And are there lessons developers in other industries can learn from those game developers to make their applications more engaging?

While this article is geared toward game developers specifically, there are multiple lessons that could apply to any application with regard to user experience and engagement. It’s especially applicable if you have a gamified corporate application or continuing education app for your enterprise users.

Much of the answer to the engagement question comes down to users’ journey before, during and after they play a game. Effectively communicating why someone should download a mobile game is the first step, but communicating with players during and after their experience is equally important for long-term engagement and overall experience.

A vast majority of mobile games still don’t implement basic messaging best practices for improving user engagement and retention. At the same time, COVID-19 has raised the bar for digital experiences. More than ever, game developers need to improve their communication strategies to survive and succeed.

One difference between established gamers and the large number of new gamers from the pandemic is that they are increasingly diverse. This wave of new gamers are also more likely to play on their mobile device, or even across multiple devices like their smartphone and tablet, which will likely require a friendlier, more streamlined experience than their more experienced peers.

Hence, creating the right communication strategy, whether through in-game events, updates on exciting new content, or relevant promotions, will all go a long way in keeping gamers coming back after they hit close.

User Onboarding is Crucial

There’s been over a 700% increase in game titles available on the Apple and Google app stores in the past decade, with nearly a million titles to choose from. With so much more competition, developers struggle to find and keep players; the top 25% of mobile games have an average 28 day retention rate of just 4%.

Mobile games have minutes (or even seconds) to convey value and engage users. How a game onboards a player can mean the difference between a loyal customer and a missed opportunity. If you drop a player into a game with no support or context, they might fumble through the rules and features, and could get frustrated enough to abandon the game.

Here are some ways to onboard players more effectively:

Function-Oriented Onboarding – This can take the form of a deck-of-cards tutorial immediately after a user opens your game. Through full-screen in-app messages, it educates the player on game mechanics, app navigation and enables players to swipe through the information at their own pace.

Benefit-Oriented Onboarding – This method reveals features that improve the player’s experience in addition to the game’s basic mechanics. For example, highlighting how a user can resume from a checkpoint instead of starting over.

Progressive Onboarding – This method helps players interact with the game interface and guides them through different actions when they reach milestones in the game. It’s well-suited to games that have more complex or varied mechanics.

Enhancing the Post-Game Messaging Experience

Re-engaging users outside of the game through push notifications, email messages or even SMS can be incredibly powerful. At the same time, if your message’s quality does not match the quality of your in-game experience, users are much more likely to block your messages or uninstall your game entirely.

The differences come down to personalization, timeliness and progression.

Players want to get recognition for their achievements and milestones, plus get instantly notified about making their next move, attack or strategy. Generic messages like, “You haven’t played in a while. Come back today!” are unlikely to have much of an impact on user retention. Instead, enhancing the in-game experience with personalized messages that provide incentives tend to perform far better: “Congrats, Matilda! Your hero is nearly at level 10 – get double XP for every level you complete today!” is a much more engaging option.

In Zynga’s popular “Words with Friends” game, the granular personalization of notifications tells users when a friend made a move, which word they played and its point value. This helps increase messaging utility and encourage reengagement by promoting friendly competition.

Another way to enhance the experience both within and outside of the game is by leveraging achievements and recognition. These can turn a mundane milestone into a moment of celebration, or convince a player to return to the game to get another reward. Displaying the daily high score of top players can also motivate players. With set goals, players strive to achieve a higher score, push harder to win a level, and play the game more.

Developers who only focus on building great game mechanics often overlook basic (and critical) communication features to engage and retain users. By employing these best practices for engagement, game developers can build a solid, growing community of happy players that keep coming back for more.

May 6, 2021
Using RPA for DevOps Process Automation

Modern operations teams today are at the cutting edge of automation. DevOps and SRE practices are entirely based on an automation-first philosophy. CI/CD is fully automated and the next generation of automated testing is now being adopted.

However, these same teams are still running their human processes based on hastily thrown-together wiki pages. The increase in remote work over the last year has amplified the problem. Engineering teams that were used to quickly getting the right people physically into a war room now struggle to find the people with the right knowledge to troubleshoot or resolve a problem.

Teams with ample resources have built tools and bots for DevOps process automation and orchestration. These tools can help automate things like getting communications channels set up quickly, with the right people, the moment an incident is identified. Or, they may automate actions across the DevOps toolchain that would otherwise live as static documentation for an on-call engineer to try to decipher and execute. But only a handful of organizations have the resources to build this kind of automation technology in-house.

These higher-level DevOps processes are ripe for innovation similar to robotic process automation (RPA). Companies like UiPath and Automation Anywhere have shown that there’s an enormous market for this in every business unit and industry. Process automation for DevOps needs to be another layer of automation available to any engineering team. Automated remediation of incidents and resolution of service desk tickets has to be the future of this space. However, there are important differences in how automation is optimized for DevOps versus the application of RPA for business functions.

Where RPA Fits on the Automation Spectrum

RPA is great for solving deterministic problems – those that can be resolved in the same way every time you run into them – which are fully automatable. An example of this type of end-to-end automation is any back-office task, which are consistently good candidates for the application of automation. It’s the reason why fields like HR and finance have made some of the greatest progress in automating business processes to date. Every time you close the books, for example, the steps are pretty similar.

Process automation for DevOps and SRE, however, is on the other end of the spectrum. Although teams may benefit from RPA for simplistic, repeatable tasks, many DevOps processes are dynamic and unpredictable, making full end-to-end automation too often fallible. The complexity of modern technology stacks and infrastructure requires processes to be agile and adaptable to change, rather than deterministic. This is where it’s important to enable humans to step into the spectrum of automation. Human-in-the-loop automation – the idea that lets humans be in the cockpit while letting machines provide guidance and support – is the future of DevOps automation.

Applying Process Automation to DevOps

To use automation in a meaningful way, DevOps teams need a mix of what RPA provides with the added element of human judgment. Human-in-the-loop automation can be applied to numerous DevOps processes including incident management, service requests and continuous deployment and delivery.

Rather than automating from end-to-end right from the start, DevOps teams should use incremental automation to strengthen and build trust in automation. This starts by codifying free-form processes so teams can more easily identify predictable steps that can be automated. Then teams can mature to more complex workflows, automating pieces within processes and incorporating human checkpoints for areas that will need judgment or approvals.

As teams incrementally automate, they build up sustainability – in their systems and their roles – in high-stress environments and are able to orchestrate processes across the continuum. The goal is to find the right balance between leveraging machines to make lives easier while creating room for human judgment and adaptability.

Level-Up DevOps Automation

Looking ahead to the next few years, what the RPA movement did for back office tasks will also happen for DevOps and SRE. Technology leaders can take notes from the RPA movement and apply them to eliminating the toil of modern production operations. The issue is that, in DevOps, many problems are unique.

The next evolution of DevOps automation will force us to look at how we can model the real world in a more holistic way, which includes incorporating human judgement and manual execution of non-repeatable tasks while automating repetitive steps.

May 6, 2021
The Time for Collaborative Security Is Now

As Bruce Schneier famously said, “security is a process, not a product.” We commonly see companies pour millions of dollars into cybersecurity products and tools to protect against vulnerabilities and lower risks, and yet, more often than not these ample funds are not enough to defend against attacks.

Within the span of two decades, we have seen how social power can be leveraged to benefit the masses with applications like Waze, Airbnb, Uber and many others. This same innovative idea could revolutionize the way the cyber world operates by giving security professionals the edge in identifying potential threats.

CrowdSec CEO Philippe Humeau recognizes the capabilities of crowd power to invigorate the cyber realm. The community firewall created by CrowdSec uncovers thousands of malicious IP addresses worldwide and helps cripple hacker behavior before it can evolve into major cyberattacks and data breaches. Additionally, the start up just announced it raised $5 million to help take the collaborative firewall to the next level as they work to transform the cybersecurity landscape.

In the interview below, Philippe emphasizes the benefits of collaborative, open and transparent security environments in tipping the scales against the hacking dilemma that plagues companies across the globe.

Join Philippe at DevOps Connect 2021 on May 19, during the RSA Conference, where he expands on this topic in his session “The Age of Collaborative Security.” Also, learn more about CrowdSec and see a demo of the tool during his spotlight session, “Introducing CrowdSec, The Open-Source Massively Multiplayer Firewall.”

To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.

May 5, 2021
China’s Open Source Activity Surged in 2020

Activity among China-based open source project contributors and creators surged in 2020, as Alibaba, Huawei, Tencent and other leading Chinese tech companies are playing an increasingly important role in the open source development community worldwide.

According to the recently released Open Source Contributor Index (OSCI) ranking, as of March 2021, Alibaba, Huawei, and Tencent collectively ranked in the top 20 worldwide for the first time. Rankings are based on the total number of contributors and contributions on GitHub. Microsoft, Google and Red Hat ranked first, second and third, respectively.

Alibaba, as well as China-based Pingcap, came within striking distance of reaching the top 20 worldwide open source ranking for 2020 measured in activity; the total number of forks, commits, stars, pull requests, issue comments and other metrics, according to the GitHub 2020 Digital Insight Report released in April.

Authored by X-lab in conjunction with East China Normal University, Kaiyuanshe, Shanghai Open Source Information Technology Association and other unnamed “scientific research institutions and open source community institutes,” the X-lab report revealed Pingcap’s eponymous Pingcap (a distributed relational database) and Alibaba’s AntDesign (a Microsoft React framework) activity metrics of 210 and 193, respectively, in 2020. Meanwhile, jwasham (an open source study plan detailing how to become a software engineer) ranked 20th worldwide with an activity metric of 234.

Open Elastic’s Kibana, recently forked by Amazon Web Services (AWS) and Kubernetes ranked first and second worldwide with activity metrics of 698 and 602, respectively.

Torsten Volk, an analyst for Enterprise Management Associates (EMA), says the increased popularity of and activity in China-based open source projects are proof that the concept behind open source software actually works.

“This is the classic ‘one plus one adds up to more than only two’ theory, and that applies to most companies anywhere in the world. And if it was possibly to gain advantages by only using open source code but not contributing, companies anywhere else in the world would have done so right from the start,” says Volk. “Remember that the core idea behind open source software is not to give out your secret sauce for other companies to enjoy for free, but to spend the least possible amount of funding on building commodity code.”

What, if anything, China-backed open source projects means for the community worldwide — as well as China’s influence in the industry in general – remain to be seen. Tencent, which entered the top 20 in March ranked by contributors in the OSCI study, for example, has become a leading supplier of components for machine learning (ML) databases in, for example, Kubernetes and cloud-native environments.

“This is great for everyone, and there is no benefit for anyone to purposefully not contribute to a project they benefit from. The benefit comes from your own contributions, in terms of reputation and credibility gain, across your industry. This motivates others to also contribute, as there is little to no benefit in keeping your own code secret while self-serving from the GitHub buffet,” says Volk. “As in the case of Kubernetes, your own company’s differentiation needs to come from the manner your proprietary apps [integrate] on top of this platform, or from the way you are able to integrate Kubernetes clusters with machine learning databases and other elements higher up the stack. And that’s why open source works.”

May 5, 2021
How to Spot SRE Adoption Barriers
It’s no secret that site reliability engineering (SRE) adoption is growing. The operating model, it seems, is pivotal for digital transformations across the enterprise. According to the Upskilling 2021: Enterprise DevOps Skills Report, 22% of respondents (up 7% from last year) cited SRE as the approach they need to continue automation in 2021.

Common Adoption Barriers

However, for some companies, adopting SRE principles and practices isn’t always easy. Ahead of the upcoming SKILup Day conference focused on SRE (Register for SKILup Day: SRE here), I asked several DevOps Institute Ambassadors and SRE subject matter experts to provide insights into the barriers of SRE adoption. Here’s what they shared:

Marc Hornbeek, CEO and Principal Consultant at Engineering DevOps Consulting and author of the book, “Engineering DevOps”

“The primary barrier for SRE adoption is executive vision and team alignment around a goal to transform to SRE practices. SRE affects the entire organization’s practices, roles and investment priorities. Without an executive sponsor, SRE transformations are not going to go far.”

Stephen Walters, Solution Architect at xMatters, Inc.

“Culture, and in particular, cultural change, is the greatest barrier to SRE adoption. As much as everything about the human race, the things that got us to being the creatures we are today, is about evolution, which is change, and we are not particularly good at it. Or, more specifically, the bigger the change, the more resistant we are to it. It has always been a great oxymoron in IT philosophy that in order to “transform,” you must change, but that transformation is occurring because we are not good at change. So it was with agile in the early days. Organizations wishing to transform to agile (small, iterative change) would do so under a transformation project, which would typically be waterfall (big bang). Big change, big cultural resistance. The key is to implement transformation in smaller, agile chunks. They are more easily accepted and testable, and also easier to roll back or adapt if they do not work or are not acceptable. All of the benefits of agile development apply to agile transformation.

The second greatest barrier is, then, “buy-in,” where the simple answer is, unfortunately, show the end user “what is in it for them.” This will typically override the enterprise-scale view of “what is in it for us?” but, over time, with any cultural transformation, this is one of the things that should change, iteratively, and also be a focus for developing a more holistic and empathetic culture.”

Shivagami Gugan, Chief Technology Officer at CX Tech Unicorn

“Any organization, irrespective of whichever level of maturity they currently exist on today, can adopt SRE and improve their business outcomes. However, the key underlying principles of SRE and its applicability should be understood properly. There is a lot of hype around transformation and the first barrier is about understanding what SRE means within your organizational context. I find most of the time, people try to imitate what highly mature companies like Google or Spotify or some other cloud-born company does, and this usually results in failures. SRE is the purest form of the implementation of DevOps. SRE is about removing the silos in a product life cycle to achieve business outcomes in a safer, faster, cheaper and better manner. If this is understood clearly, the first barrier gets removed.

The second barrier is this complicated vision of boiling the ocean – doing 100% Agile, 100% DevOps or 100% SRE. This doesn’t work, especially when you have heritage systems of records, on-premises services and heritage infrastructure and a whole lot of baggage built over several years (sometimes decades) which is the usual case for most companies. So be very clear in choosing target areas.

The third barrier is when you think SREs specialize in building operational reliability, but do not have anything to do with the development or the deployment phases of the life cycle. Reliability is everyone’s problem – the technical product manager, the developer, the tester, the support engineer; not just the SREs. The reality of the SRE role is to ensure services availability and reliability by supporting the other teams that own these services. SREs are enablers, they are collaborators, and their goal is to ensure that the services are overall resilient, reliable and that incremental value is delivered in a continual manner. When an organization understands that implementing SRE is an underpinning cultural change that affects all parts of the organization, then it becomes easier to remove the main barriers.”

Lisa Chan, Head of Software Engineering & DevOps at PETRONAS

“Not all organizations have the luxury of having an Ops team composed of skilled developers, which is a key success factor for the adoption of the SRE working model. In my case, I’m in an IT organization of 1,800 folks that has supported an oil and gas company since its inception 40 years ago. We serve a captive market of an integrated energy business with more than 100 companies under its portfolio. As a result, there is a legacy landscape of more than 2000+ applications. The IT organization still maintains the common “Dev is Dev, and Ops is Ops” anti-pattern. Even though we are in transition towards a working model that is more collaborative, it is unrealistic to expect our 300 Ops personnel to reskill themselves to be developers, because many of them have traditional skill sets along the typical Ops silos; e.g., networking, database admins, server admins, data center management, call center agents, etc.”

BMK Lakshminarayanan, Value Stream Architect at Bank of New Zealand

“Building the SRE practices and skills within enterprises are always challenging, as some are still embroiled with old ways of thinking. The thinking, associated techniques, available tools and limited skills are constraining SRE adoption in most enterprises.

Renaming the system admins to SREs neither helps nor makes SRE experts. Investing in expensive tools doesn’t help, either. Any adoption and transformation is a gradual process. A typical medium to large enterprise has a few hundred systems, applications and services with various operating systems to support, database platforms to manage and hundreds of application databases to monitor or administrate. To this complexity, add all the dependencies of other services and components, as well. Hence, redefining the SLOs, SLAs and SLIs for these services, automating everyday maintenance tasks, understanding the toil, building resilience and fault-tolerant characteristics within these systems and applications are uphill tasks for most enterprises.”

Identifying Other Common Adoption Barriers

Many other common barriers for enterprises are:
- Availability of up-to-date system and application information in a centralized platform
- Observable nature of legacy systems
- Understanding the dependencies and service levels (Promise Theory)
- Availability of the right tools for the right job
- Skills – old ways do not open new doors.
- Time – time and space for people to upskill, train and experiment.
Want to learn more about SRE and how to overcome these adoption barriers? Join us for SKILup Day: Site Reliability Engineering on May 20. Register here: https://devopsinstitute.com/sre-2021/.
May 5, 2021
How to Bring DevOps and Security Teams Closer Together

More often than not, there seems to be friction between DevOps and security teams. Despite having the same end goals of creating the most secure code and preventing any potential security pitfalls, these groups of professionals often lack the unity needed to accomplish these end goals effectively and efficiently.

In the interview below, Naomi Buckwalter, director of information security and IT at Beam Technologies, addresses this issue and outlines key ways development and security teams can come together to better accomplish their shared missions. She stresses the importance of security professionals reaching out a hand to their DevOps counterparts to teach them how to be security-forward when writing code. However, she highlights how not every security expert has a developer background, so it really takes these two groups of skilled tech specialists working in unison to fill those knowledge gaps for each other.

Naomi brings over 20 years of IT and security experience to her upcoming session “Six Things Developers Want From InfoSec,” at DevOps Connect 2021, during the RSA Conference. She will expand on some of the key topics discussed in this interview during her talk on May 19 at 4 p.m. EDT.

To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.

May 4, 2021
5 Steps to an Open Source DevOps Strategy

Open source technology thrives during times of mass disruption, and this pandemic has been no different. Across the board, companies are accelerating their digital transformation and DevOps strategies, looking to open source technology as a way to streamline operations. While deploying open source software (OSS) in DevOps can help organizations lower costs and avoid vendor lock-in, the tools are often not backed by an ecosystem that makes them transferable across the enterprise, leading to interoperability issues across the board and creating a haphazard workflow.

Before embarking on an open source migration, companies need to plan out their strategy. Following these five steps will help companies create an organized plan and a seamless open source stack so that they can capitalize on the lower costs and tap into the benefits of the open source community.

Determine if you Can Self-Support Your Strategy

A recent Gartner study determined that at least 75% of open source policies don’t yield effective results. This stat is largely due to companies believing that they can self-support their open source stack. However, as technology becomes increasingly complicated, companies should take a step back and evaluate if they actually have the right resources and skill sets to get the job done. Enterprise architects with open source expertise are a niche group that’s in high demand, so don’t worry if you don’t have the resources – there are plenty of trusted vendors out there who have a proven track record of delivering results.

Consolidate

Fewer vendors equal fewer problems. When evaluating potential partners, keep in mind that working with a few key partners (versus several) will be beneficial in the long run by ensuring that applications will work together seamlessly, while also avoiding vendor finger-pointing if they don’t. Assess potential partners to see which packages, application stacks and infrastructure they support, and what level of freedom you have to switch out various components. Avoiding vendor lock-in is key, as switching vendors will be a costly undertaking if you ultimately decide to go in another direction.

Invest in Security

Security is a major concern in enterprise open source software, and it’s critical to make sure you have the ability to act quickly on potential issues and vulnerabilities. Consider partnering with a vendor who specializes in OSS security, and can keep clients informed of the latest security updates and bug fixes to ensure that your program isn’t vulnerable to security threats. Having a security specialist on standby is a must-have for organizations so that when security is breached, it can be remediated immediately.

Pick the Right Tools

Not all tools are alike. There are plenty of options out there that can help elevate your open source strategy, but consider how each will affect your overall program. At each phase of your pipeline, test the open source tools selected to ensure that they can integrate together within the broader toolchain and every layer of your software stack, including databases, platforms and monitoring solutions. If you have questions about their connectivity, either consult with an expert who understands how the software will truly behave in various environments or engage with free apps that help developers determine if their tools are compatible across the broader stack. Doing so will help enterprises choose the right open source technology early on, saving both time and money.

Adapt

Open source implementation in DevOps is more than a one and done approach; it requires adapting and tweaking in order to stay relevant, keep a competitive advantage and optimize new technology. Ensure that your open source strategy can be improved to include new offerings and services that the company will implement down the road and that your vendors—or internal team—can modify the framework fairly easily when necessary.

While open source technology continues to drive innovation in the DevOps industry, including it in a company’s DevOps strategy requires thoughtful planning. When done right, an open source policy will save a company time, money and people power, allowing them to collaborate seamlessly with the greatest minds in the industry.

May 4, 2021
Reducing Friction in Developer Collaboration

Given how the individual unit of deployment has gotten increasingly smaller, such that the unit of deployment is usually a microservice, it would be tempting to think that individual developers are more able to control how well the code they write (the service they deploy) will work in production. In fact, though, almost the opposite is true. Instead, as the number of services in an environment increases, whether or not one service will work correctly in a production environment has more to do with how well it works with other services rather than the quality of the code.

This makes collaboration between developers even more critical than ever before, but the packaging of code in microservices actually makes collaboration more challenging. Developers don’t collaborate by working together on a shared codebase — instead they work completely independently on services that could easily be written in different languages, providing the illusion of complete independence.

In most organizations, ensuring that services work together is a largely informal process. It’s managed by walking over to a colleague’s work station and asking what updates they’re working on or what version libraries they’re using. In a remote work environment, teams rely on Slack messages or Zoom calls to solve issues relating to services interaction. This creates a lot of friction for something that is a critical part of the software development workflow. Failures in service integration can and do cause problems in production.

Pay Attention to Service Communications

A perfectly crafted microservice is not going to run in isolation in the production environment. Compatibility issues between each service and upstream and downstream dependencies are just as likely to cause bugs, downtime and poor performance as problems with the code deployed in a container.

The only way to catch compatibility issues before production is for developers to work together and communicate about the updates they’re working on and how those might impact interdependent services. In the current system, however, this level of collaboration introduces a lot of friction in the development workflow, reducing the individual’s and the team’s velocity. Since developers are generally evaluated based on velocity and code quality — but not necessarily on how well their services work with other services — if the friction remains, developers will be tempted to deploy without fully understanding how dependencies will be impacted.

Since CI/CD pipelines are generally not set up to test how well services communicate with each other, problems with service fit that aren’t addressed at the development stage generally aren’t found until either a canary deployment goes wrong or there are problems in production.

Replacing Tribal Knowledge

One of the other reasons companies need to focus on developer collaboration is that remote work has made it even harder to communicate tribal knowledge. In my experience, no development team has been able to completely wean themselves off of tribal knowledge. Even teams with extensive technical documentation often had or have experienced team members who maintain a unique understanding of the application’s business logic and can share that knowledge when needed.

Tribal knowledge also relates to service integration and communication — often, insights about how services work together isn’t well-documented, even if each individual service is well-documented. Often, the easiest way to see how they would work together is not to have the two developers responsible for each service work together, but rather to have a senior developer take a look. Especially as development teams work remotely, that type of review isn’t feasible.

How to Help Developers Collaborate

Most teams have ways for teams to communicate — they have a Slack setup, they have internal forums and video conferencing solutions. But they often don’t realize that these communication platforms aren’t really collaboration platforms — they are not providing a way for developers to actually work together on interdependent services the way they might if working on a shared codebase. Communication isn’t enough for true collaboration to happen — developers need a way to work together and see how colleagues’ changes impact their own services.

Facilitating true collaboration, the kind you would get from two people looking at the same screen and coming up with solutions together, is more challenging than making it easier for developers to talk to each other. Without true collaboration, teams will continue to have trouble with communication between services — and there’s no Slack for that.

April 27, 2021