devopsy.kinsta.cloud

Tag: devops teams

Why Modernizing Security is Like Visiting a Fast-Food Restaurant
Fast casual restaurants are taking over the food industry. Today’s consumers want quality and speed, and the brick-and-mortar model offering immediate service paired with quality ingredients perfectly fits the bill. It’s the new, modernized dining experience. You can also argue that the same modernization taking the food industry by storm is happening in the security sector.

Simply put, fast-food restaurants know what their customers want: food that’s served hot, fresh and quickly–all while being made to order. And while the needs of a fast-food customer may seem far from the security needs of an organization, it isn’t too far off. Just like a fast-food customer, DevOps teams are hungry for a streamlined process. However, in their case, this doesn’t come in the form of a fried chicken sandwich; rather, an app infrastructure that is low-latency, secure and brings visibility.

According to the 2018 Verizon Data Breach Investigations Report, web application attacks are the leading source of data breaches. This suggests security procedures are not keeping up with modern systems and vice versa, which means they’re not keeping up with the modern customer, who has increased security needs due to demands for fast, interactive, web-based experiences with vendors. From food service to security, many industries are learning that, to succeed today, you’ve got to combine the old with the new.

As technology evolves, systems must as well. When it comes to security, it does not make sense to continue using a legacy WAF built for a decades-old line of defense. Today’s technology and applications require next-gen WAF systems that can keep up with the changing infrastructures and the evolving threat landscape. The risk is too great to sit back and do nothing.

Security teams today often find themselves either supporting new infrastructure initiatives or inheriting legacy applications and systems. Determining where an application is running can be a challenge. Rather than simply pointing to a rack of servers to locate an app, security professionals now must look to the cloud. However, this presents another obstacle: container orchestration. Kubernetes or otherwise, the options are not always clear-cut.

A modern infrastructure mix is made up of many parts (much like a layered chicken sandwich): cloud, containers, hardware, platforms—and sometimes serverless. Flexibility and deployment options are essential to defending applications and APIs across multiple components and delivery stacks. Typically, security teams end up in a balancing act of supporting new infrastructure plans while taking over existing legacy systems and applications.

To be adequately protected, security teams must evaluate defensive tools, open source or commercial, for use in:
- Major cloud providers (e.g. AWS, Azure, IBM, GCE)
- Container platforms (e.g. Kubernetes, Docker)
- Hardware and web servers (e.g. load balancers, NGINX+)
- Serverless options (e.g. API gateways)
- Platform services (e.g. Heroku, language plugins)
- Cloud-based deployment models (e.g. hosted cloud WAF)
The modern world is ever-evolving and the definition of “modern” changes as new technology is introduced. Fast-food chains have evolved over the years and, in turn, moved the food industry forward with the introduction of fast, casual and reliable options. The companies continue to evolve to meet the customers’ demands by introducing delivery services, unique rewards programs and leading mobile apps.

The security world can learn a thing or two from the fast-food chains’ commitment to continued business evolution. Much like the way fast-food customers are quick to jump ship if they don’t see the selection they want, legacy WAF customers are learning they can make a change to other security solutions if features and infrastructure aren’t evolving.

The simple truth is legacy WAF solutions can’t accommodate today’s technology and applications, exactly how traditional fast-food can’t keep up with customers’ growing demand for tasty yet quick meal options. This leaves proprietary data exposed and vulnerable to attacks. It’s time for security leaders to take action and upgrade their systems while getting their teams up to speed without sacrificing security of their vital assets.

— Jonathan DiVincenzo
August 12, 2019
DevOps at the Speed of Business: 5 Tips for Success

It’s an exciting time to be an engineer. With companies today moving faster than ever, engineering teams are developing and deploying new code daily, continuously improving and advancing the business. But while the pace of modern development creates new opportunities for engineering teams, it introduces new challenges as well—in particular, making sure new code releases don’t bring the system crashing down. With more code comes more opportunity for error.

When organizations scale fast, the challenges compound. As the engineering team grows to keep pace with expanding business, it becomes more difficult to keep track of the new code being developed. This lack of visibility can frustrate even the best teams. Without a clear view into what changes are being made, it becomes more difficult to fix them when something goes wrong.

What do you do? Here are five key DevOps practices critical for organizations scaling fast:

Put a Premium on Collaboration and Communication

DevOps teams, no matter their size, need to be able to share information easily and quickly. When a problem occurs, forensics and root cause analysis must be performed as fast as possible, and engineers need to be able to annotate events that occur within the product deployment stream. Most companies already have the tools to do this, but they often fail to communicate what they find. Opening lines of communication between disparate, often geographically dispersed teams enables everyone to expand beyond their own knowledge base and capabilities to help one another. When everyone can share their knowledge, it raises the collective talent of the entire engineering community, creating a more collaborative learning environment and a culture of sharing.

Democratize the Tools

Tools that are accessible only to a small group of power users always fail. There’s not a person in the world who wants to put hours into teaching themselves a new tool if it isn’t approachable and interesting. That’s trouble, because the fewer people that understand how to use a given tool, the more difficult it is to use it to fix a problem. For example, if the ability to query log files is limited to the three engineers who are certified on a tool, the size of your team won’t matter; you can have 50,000 of the best engineers, but effectively, it’s a team of three. This bottleneck can have serious business consequences. Imagine you’re an online retailer having your biggest sale of the year and your website crashes. Every minute you spend finding an authorized user is a minute lost, and when the internet is your business, time is quite literally money.

Spread Recognition of Value

No one wants their work to go unnoticed, but recognition is a learned practice and one that requires continued focus. DevOps teams and their work save their organizations vast amounts of time and money, and business leaders should take care to highlight the value of their team’s successes, both internally and externally. Not only does it encourage their teams to work harder and smarter, impacting the entire organization, but it also lifts up DevOps teams everywhere, publicizing best practices to outside teams and creating an exponential impact across the entire engineering community.

Don’t Just Expect Change, Embrace It

Innovation generally happens for two reasons: The tools being used to solve problems aren’t working, or the problems you’re trying to solve have changed. Every day, companies get frozen in time—the tools they use may work now, but the world around them is changing. It’s easy to get caught in a cycle of developing new products, but what if the tools your business uses to solve problems are out of date? When engineers make changes in the code, they must be in lockstep with every other department, from QA to customer service. Organizations that embrace change always will have a leg up on the competition.

Capture Your Knowledge Base

As business scales, their teams scale with them. What once may have been a two- or three-person DevOps team becomes a 40 person machine, and with scale comes a lack of coordination. More and more, DevOps teams are scattered across the globe, in offices and remote, and no two people have the same workflow. In this fragmented environment, it becomes imperative for companies to keep a store of knowledge their engineers can reference wherever they are, whenever they need to.

Fostering a strong DevOps culture isn’t easy, but it’s necessary. At its core, DevOps is about collaboration and communication—companies that treat each team as separate units risk siloing their employees, creating closed information channels that are difficult to break through in times of crisis. Whether you’re pushing new code or bringing your business back online, timing is everything and engineers need to be able to move at the speed of business. These five tips won’t fix your code or craft new features, but they’ll certainly ease the process.

— Dave McAllister

July 22, 2019
How to Rethink Sprint Retrospectives to Shape a Better Culture
If you have been in a scrum team (or even an agile software development team), you most certainly have had or heard about sprint retrospectives or gone through them. They often happen after the team showcases the work done during the sprint reviews or demos. The original intent behind retrospectives is to help the team learn and improve faster as a whole, with an iteration at every sprint. What if sprint retrospectives could be rethought so that it stimulates more motivation and learning for the team at every iteration, and have its value spread across the whole organization? Growing knowledge and awareness within your team is great, but growing knowledge and awareness in your whole organization (including other departments) is better.

The fact is retrospectives are part and parcel of the engineering culture, but also the company culture. In this article, we will quickly go over the current way of doing retrospectives, before seeing the different ways their impact can be strengthened.

What Is a Sprint Retrospective?

There are plenty of resources about what a sprint retrospective is. Simply put, the sprint retrospective meeting lets you analyze your process in the previous sprint and create a plan for improvements in the next. It gives the scrum team the opportunity to ask and address questions such as:
- What did we do right in the previous sprint?
- What did we do wrong in the previous sprint?
- What should we start doing in the next sprint?
- What should we stop doing in the next sprint?
- What can we do to improve productivity?
You want to keep these simple and short, and possibly use some templates, so that the team can easily memorize and improve on every iteration. You would want to keep the team focused, otherwise it can just turn in a social gathering. The retrospective can even include some thinking about the retrospective process itself. Nothing is out of bounds.

Be careful to avoid bashing or criticizing, as well as allowing boredom. If the same question is repeated at every retrospective, your team might not participate anymore. If the same questions arise, what can we do differently so that it is finally fixed?

Overall, the end goal is self-improvement as a team that always strives to perform better, as well as self-improvement for every individual, scrum master and product owner.

What’s Wrong with Current Sprint Retrospectives?

There is nothing wrong with the way we handle retrospectives currently, per se. It’s just that there are huge missed opportunities. Sprint retrospectives are about growing the team as a whole as well as all its team members. And, think of the possibilities if we were able to do the same across the organization?

Actually, sprint retrospectives are much more part of the organizational culture than we might initially think. It’s among the few things that happen on a weekly or bi-weekly basis with other team members. Doing sprint reviews, demos and retrospectives the right way will shape your team and individual growth, in addition to the organization’s talent retention.

Sure, there are a few well-documented things that you need to be wary of when doing a retrospective. I’ll list them fast but won’t dwell on them because that is not the point of this article.
- Boredom: Having the same questions asked regularly will get your team bored and the feeling that retrospectives are useless. One way to avoid this is to change things a bit. Iterate on the retrospective itself or have a different retrospective meeting leader each time.
- Lack of candid conversation: Without conversations, feedback and ideas flowing, retrospectives are useless. It’s important to foster participation from everybody. If you see a lot of blank stares, it might be useful to think about other ways to get participation such as putting ideas on paper anonymously. But at some point, your team needs to feel comfortable to share their ideas without fear.
- Ego: It’s vital to put the team productivity above individual needs. There shouldn’t be any place for emotions, as it will thwart honest conversations from happening.
- Disagreements: It’s more than okay to disagree. There is a quote that says “diversity in counsel, unity in command.” The more disagreements, the more ideas will be flowing, and the end result will be the best ideas. However, once an agreement is made, everybody needs to unite behind the decision
- Conflicting agreements: Let’s face it, that can happen. In the end, a decision needs to be made, and as stated above, then everybody needs to get behind the decision.
- Tired of change: Attempting too many improvements may actually prevent the team from improving. In that case, making sure everyone is keeping up is the most important. Sometimes it’s best not to change anything, but just to retry as becoming good at something takes time and persistence. Also, it might mean it’s time to iterate on the sprint retrospective itself.
4 Ways to Rethink and Improve Sprint Retrospectives

Now, let’s see what we can do to improve retrospectives, as well as spread its benefits throughout the organization by improving its culture. Some of these points will directly address some of the speed bumps mentioned above.
1. Positive Reinforcement
You need to be very explicit about positive learning, so you have more willingness to share within the team. It might be interesting to rename the retrospective to “wins.” For instance, sprint wins or week wins, if you do those every week, or Friday wins, if the retrospective happens on Fridays.

The name will emphasize that we are here to improve and not blame. Wins can also remind people of the demos, as the new features and work done can be considered new product wins.
1. A Ship-It Culture
Software only creates value for customers once it’s shipped. That’s a fact.

Shorter cycle times lead to both higher productivity and higher satisfaction, there has been quite a lot of study on this. Only presenting work that has been shipped during the sprint demo will emphasize this point and will spread a culture of shipping fast and often. You shouldn’t present work that’s almost done or waiting to be merged to master. Deploying a developer’s work is what is most exhilarating for the developer.

By promoting a shipping culture, your team will gain more confidence and will express more motivation thanks to creating this high-velocity momentum sentiment.
1. High Energy and Inclusive
We already mentioned some retrospective techniques–only shipped features, no blaming, only positive learning. But that’s not enough if you want to have the full attention of the whole team during those retrospectives. For this reason, you need the retrospective meetings to be high-energy with time limits. Time limits can make them actually fun for both presenters and audience, as there are some kind of challenges. And everybody loves fun challenges.

But also, you need to make the whole team participate. Some teams might not have shipped anything in the sprint or week. Still, you need to find ways to make everyone part of the meeting, through questions or participation to the discussion.

Finally, why do we have sprint retrospective meetings only within teams? They create new learning opportunities for the other teams, too. That’s why they should be inclusive to anybody in the team but also to all the other teams (well, until the size of the meeting is no longer sensible).
1. Cross-Functional as Learning Can Be
Coming back to the last point about learning opportunities, it’s also a missed opportunity for other departments, too. For example, if sales and marketing better understood the progress of projects, they would gain a better understanding of how software engineering actually works. Companies that succeed have teams that respect each other’s work and collaborate well together.

Plus, it’s awfully hard to predict who needs what information in a big company. Leaving the retrospective meetings open to anyone could help people get the information they need.

So, it’s worth the effort to invest in making attendance as easy as possible–support for remote people, etc.

Would You Still Do Intra-Team Retrospectives?

Should these meetings stay only within teams? Should you have intra-team retrospectives with all the discussions, before a general one with only the demos and learnings?

The point of this article is that sprint retrospectives are a great opportunity to drive more knowledge, better collaboration and alignment throughout the whole organization. So, you should really think intentionally about what you want from these meetings.

— John Lafleur
July 3, 2019
Self-Service Workload Protection for DevOps Teams
Everyone (or almost everyone) in the DevOps world likes to talk about the importance of security. But too often, these DevOps security conversations end with generic recommendations such as, “Follow the OWASP Top 10.”

Don’t get me wrong—reference frameworks such as OWASP are great resources for helping to guide DevOps security. But it’s usually far from obvious to many DevOps teams how to bridge the gap between the abstract theory of these frameworks and actual practice. That’s especially true given that many DevOps teams spend their days putting out fires in fast-moving CI/CD environments and have little time to step back and operationalize security best practices, even if they know they should.

In this article, I’d like to present one real-world strategy for implementing the DevOps security best practices outlined by organizations such as OWASP. That strategy is what I call self-service workload protection. The term refers to making security not just something that DevOps teams recognize as important in the abstract but an easy-to-use service that anyone on the DevOps team can operationalize just like any other process within the CI/CD pipeline.

In other words, we need a self-service approach for offering workload protection through an accessible library of policies and tooling that DevOps teams can leverage on demand. Let’s take a look at how we can achieve that in practice.

Understanding Self-Service Workloads

To understand how self-service workloads work, we need to know the common parameters that define a secure and properly configured application deployment. With that information, security teams can automate the process and offer a complete set of reusable and adaptable tools for DevOps service teams to run.

The common parameters usually boil down to the following factors:
- Making sure that all required compliance and security scans run at least once for every deployment. Those scans need to use preventive actions and block insecure deployments.
- Making sure that for any new vulnerabilities found, we add them to the list of checks. (For example, we should be able to see updated reports for new issues as they’re discovered.)
- Performing audit reports and continuous security monitors over the development and production sites to capture security issues.
- Establishing sane and pragmatic secure default policies and authorization profiles.
The above parameters should be captured and packaged as a self-service solution and used during the normal flow of operations—for example, CI/CD pipelines, validation and compliance checks, creating and uploading a new image to a container registry, etc. This means the security team will have to spend some time to make sure the application of workload protection policies is a team effort.

For more tips on automating security, check out Symantec’s recent webinar on security and compliance for DevOps.

How to Make Security Better Via Self-Service Workload Protection

From the perspective of the security team, the main goal is to make security accessible to everyone in the organization. Not only that, but the tooling and resources they offer need to be documented and easy to use. The DevOps team should be able to plug in security controls without knowing their ins and outs, though they need to have the means to let the security team know if something goes wrong. Let’s explore how we can make this process better.

Shift-Left Security Through CI/CD Pipelines

Shift-left security is the main focus point of the security team, and it’s also the most tricky to get right. By adding more security checks and audits earlier in the development process, there’s a risk of stepping into other people’s ponds (which may degrade their workflow experience).

A better approach is to give more responsibility to the DevOps team and let them determine the best possible integration point. Mistakes will be made, but important lessons will be learned. Gather feedback from the process and, if required, iterate over the agreeables. That way, everyone will benefit. If the appropriate steps are taken, the security team will have a way to apply its security checks during the development process, and the DevOps team will have its infrastructure protected (at least from known risks).

Test automation and continuous integration points are the most obvious solutions, as they are the most automated parts of the system. The security team can go the extra mile and offer reusable policies and deployment steps that can be added on each deployment type. For example, they could offer a container image that is bundled with security checks and frameworks that test common security issues. The DevOps team can simply enable the checks via the CI/CD dashboard and during the build stage the check would act as a gateway if a security check fails.

In addition, the security team can share infrastructure policies and secure default configuration via infrastructure-as-code tools such as Terraform using remote state. This could be enabled during infrastructure provisioning by the DevOps team, without configuring anything. Sharing state this way often improves collaboration between departments.

Pre-Baked Secure Images

Developers use VMs and containers to package their apps for the DevOps team to deploy them to production. Usually, those images host crucial configuration and services that are specific to that application. What’s more ideal than to have the security team prepare a list of safe-to-use images that are preconfigured with secure defaults and scanned against vulnerabilities? Developers just have to specify the required image by ID so that the DevOps team can use it for all deployments.

Tip: Symantec’s CWP product is integrates with Jenkins to enable simple, automated vulnerability scanning during the CI/CD process.

For example, tools such as Packer are used to create identical images for AWS compute instances, and features such as seccomp profiles are enforced to Docker images. With Packer, you can deploy consistent images to the cloud and integrate vulnerability scanning into the process to ensure the deployed images meet GSO guidelines. There is a small caveat here, though: If developers decide to add an external library that needs more capabilities and they don’t inform the security team, then the application might misbehave in production and the DevOps team would be caught unaware. So, it’s important to have a good communication channel and do a security assessment for each new dependency or change introduced to the system. This keeps the self-service agreement working without interruptions or misunderstandings.

Conclusion

Letting the DevOps team manage its own self-service affairs when it comes to security controls and compliance requirements is the next major step toward a more productive business model. There are additional costs, but the end results have long-term advantages.

By having a preset repository of tooling, configuration policies and pre-baked images accessed from secure portals, teams can integrate security from the start while maintaining the benefits of accelerated development. And by doing that, security and DevOps teams can improve their collaboration.

That’s great news. What’s even better is that we can use a tool that is suited for all the above tasks—Workload Security Protection from Symantec. If you want to learn more about the platform, see how it can help secure your cloud with a free trial.

This sponsored article was written on behalf of Symantec.

— Theo Despoudis
June 27, 2019
How to Improve DevOps Visibility
DevOps, by design, works quickly and accomplishes deadline-driven projects rapidly. With a high amount of project turnover, visibility into key operational data is easy to mismanage and can lead to simple mistakes, lack of optimization and organizational misalignment. To examine the effect of DevOps visibility, SmartDraw commissioned the “2019 DevOps Visibility Report.” The results were decisive: Each company surveyed is seeking ways to better DevOps visibility, and 84% of respondents list it as somewhat to extremely important to their organization. But achieving DevOps visibility is not always simple.

Roadblocks to Achieving DevOps Visibility

Respondents identified that visibility reports take skilled workers away from their other priorities. In a small, fast-moving lean team, removing a skilled worker from a key deadline-driven task can cause performance and timeliness to suffer.

Further, the reports often are visually complex and not useful. If the team member creating the visualization is unable to design it in a simple fashion, the report is often wasted effort as it provides no actionable insights.

Finally, and potentially the most harmful, the reports are static and do not accurately represent the current state of information. DevOps teams are meant to be agile, and poor report updating practices can lead to stale data. When that stale data is used to make decisions, organizations lose productivity and quality.

So, what should DevOps managers do to improve this process?

Key DevOps Visualization Recommendations

The “2019 DevOps Visibility Report” uncovered four insights to improve operational visibility and efficiency with expanded real-time DevOps data visualization:
- Avoid building static reports in spreadsheets: Spreadsheets, while effective at data analysis, are not the correct medium for visibility reports. The static data quickly become out of date and useless. In today’s modern business landscape of rapid change and competition, any manual work becomes a risk to an organization’s decision-making ability.
- Present common DevOps information in an easily comprehensible manner: Respondents reported challenges in reporting data in a way that a variety of audiences could comprehend. These reports are designed to be consumed by multiple levels of the organization, with varying degrees of technical knowledge. The most successful respondents focused on visualizing data in an easy-to-understand way.
- Adopt low or no-code solution for visualizing unique relational data: By utilizing a solution that is fully or mostly automated, organizations allow their skilled team members to prioritize deadline-driven work. Further, this automation allows for improving real-time information and lessens the likelihood of stakeholders making decisions based on old, outdated data.
- Create self-service reports that enable non-engineers to visualize DevOps data without submitting change requests to engineering: It’s crucial to be able to remove DevOps team members from the update process. Key stakeholders should have the ability to generate a report easily and without input from DevOps. Additionally, this report should be based on existing source data, and should allow for anyone to drill further in to see the raw numbers that the visualization is drawn from.
Conclusion

A good DevOps process improves quality, lowers cost and saves time. Yet, poor visibility can limit DevOps success and lead to misalignment. Organizations should adopt an automated real-time DevOps visibility solution to allow team members to focus on the crucial pieces of their role, provide relevant information to managers and create digestible visualizations.

— Joshua Platt
April 24, 2019
SolarWinds IT Trends Report 2019: Measuring the Skills Priority in DevOps
Although historically technology professionals were among the most adaptive specialists in the job market, a recent survey from SolarWinds found that DevOps teams, web product managers (WPMs) and developers lacked confidence in their current ability to effectively manage their current environments while engaging in future technologies. This balancing of current trends with future innovations is a necessity of having any technical role, as things change quickly in technology.

SolarWinds recently published the latest edition of its annual IT Trends Report, IT Trends Report 2019: Skills for Tech Pros of Tomorrow, which explores confidence, current and future skill sets, career development and barriers to career success to reveal how DevOps teams, developers, WPMs and the businesses they serve can better manage future technology realities. How do these tech pros personally feel about their current and future skill sets? Coinciding with SolarWinds Cloud Confessions: The Trouble with Troubleshooting,the IT Trends Report found that tech pros have an appetite to prioritize career development on a weekly basis, but are hindered by factors such as time and cost. How can they prioritize career development while confronting the barriers to career success and develop the skills necessary to make future tech implementation a reality?

The DevOps findings are based on a survey fielded in December 2018, which yielded responses from 100 DevOps practitioners (teams, developers and WPMs), managers and directors in the United States and Canada from public and private-sector small, midsize and enterprise companies.

Among many other key findings, this year’s survey revealed:

Most tech professionals in DevOps, web product managers and developer roles are not fully confident they have all the skills needed to manage their environments into the near future, especially when it comes to emerging tech.
- 75% of all DevOps teams, developers and WPMs surveyed are not “completely confident” in having all the necessary skills to successfully manage their IT environments over the next three to five years—even though 98% have worked to develop a skill over the past 12 months.
- When it comes to the idea of implementing or managing specific technologies, emerging tech is a pain point (despite how much mindshare these buzz-worthy technologies get in headlines). The top three technologies DevOps teams, developers and WPMs feel unequipped to manage with their current skill sets are:
1. 1. AI (55%)
  2. Blockchain (50%) and quantum computing (50%)
  3. Machine and/or deep learning (45%)
- According to the Gartner list of strategic technology trends that have the potential to disrupt and are on the verge of becoming more widely used in the next five years, AI, blockchain and quantum computing all rank in the top 10.
- There is a great opportunity for DevOps teams, developers and WPMs to increase their knowledge of these technologies and to have productive conversations with businesses on the reality of implementation in the near future.
DevOps teams, developers and WPMs will continue building skills in daily operations with an eye toward areas such as data science.
- In the past 12 months, DevOps teams, developers and WPMs have prioritized skills in coding and scripting (54%), systems and infrastructure management (43%) and database management (41%).
- In the next three to five years, the top two skills developers and WPMs plan to develop are security management (45%), data science and analytics (41%).
- DevOps teams’, developers’ and WPMs’ instincts are correct when it comes to the top skill set area as they’re expected to see continued growth. Gartner research analysts estimate that global revenue for the information security market will grow at a compound annual growth rate (CAGR) of 7.8% between 2017 and 2022, reaching $143 billion in constant currency terms.
- Hybrid IT deployment monitoring and management rounds out the top three skill sets DevOps teams, developers and WPMs plan to develop in the next three to five years.
- Gartner also predicts that the worldwide public cloud services market will grow by 17.33% in 2019, going from $175.8 billion in 2018 to $206.2 billion this year^.
DevOps teams, developers and WPMs say cloud and/or hybrid IT, big data analytics and AI are the key technologies for career development, which will help achieve higher goals such as innovation.
- DevOps teams, developers and WPMs say the most important technologies for their career development are (by weighted rank) aligned with the top three technologies for organizations’ transformation over the next three to five years.
1. 1. Cloud and/or hybrid IT (59%)
  2. Big data and analytics (55%)
  3. AI (54%)
- When it comes to career development goals over the next three to five years, DevOps teams, developers and WPMs will look to prioritize (by weighted rank):
1. 1. Technology innovation (49%)
  2. Programming, coding and/or scripting (33%)
  3. Data analytics and/or data science (38%)
- Management/leadership skills (people management) and IT security protocol and/or processes round out the top five career development goals for the next three to five years.
DevOps teams, developers and WPMs have an appetite to prioritize career development on a weekly basis but are hindered by factors such as time and cost.
- Nearly 8 in 10 DevOps teams, developers and WPMs (79%) say their day-to-day IT tasks extend into time earmarked for career development, with 20% saying this always happens.
- This is alarming considering DevOps teams, developers and WPMs enjoy technology skills training, with 49% finding it informative, 32% saying it’s engaging and interactive and 27% reporting it’s not long enough.
- Currently, DevOps teams, developers and WPMs engage in IT skills training and/or career development programs ranging from a few times a year (25%) to monthly (23%) and weekly (19%); however, if there were no schedule or workload restrictions, most (42%) would prefer weekly training.
- Developers and WPMs cite time and availability (48%) and cost (25%) as the biggest barriers affecting their current ability to participate in IT skills training and career development programs at the frequency they would like.
- When it comes to their primary sources for training, DevOps teams, developers and WPMs turn to:
1. 1. My organization and/or coworkers (20%) and online communities/forums (20%)
  2. Industry events/trade shows (17%)
  3. Vendor training sessions (16%) and industry publications (16%)
- However, the ideal delivery format for IT skills training according to DevOps teams, developers and WPMs is (by weighted rank):
1. 1. Self-guided online course
  2. In-person workshop/user conference (full-day)
  3. Webinar
Final Thoughts

For tech pros to continue helping businesses revolutionize current technology while proactively adapting for future disruption, it is imperative that business and technology leaders provide the training that tech pros seek, through courses, self-guided training and webinars.

SolarWinds 2019 survey results emphasize the importance of empowering tech pros through training and focusing on career development. Emerging tech should not be a pain point for these tech pros—rather, they should have the opportunity to embrace strategic technology trends and have productive conversations with businesses on the reality of implementation in the near future.

2019 is the year of integrating career growth, skills development and business transformation to empower tech pros with the skills necessary to help lead the business they support into the future of tech innovation.

— Joe Kim
April 9, 2019
What Building a March Madness Bracket Teaches About DevOps

Applying the lessons learned from the NCAA tournament to DevOps in your organization.

‘Tis the season for filling out brackets, secretly checking your favorite team’s livestream at work and watching your ranking rise and fall in the office pool.

Unless you’re this guy, your bracket is already busted. However, there’s always hope for next year, especially if you pay attention to five key indicators that experts say predict the success of teams in the NCAA championship.

But you don’t have to wait until 2020 to put these tips into action. In fact, carefully constructing a March Madness bracket can actually teach you a lot about DevOps.

The following five tips can be applied to your next bracket, as well as your software development team:

Don’t Rely on Offense Alone

A great offense is key to scoring, but the gap between offensive and defensive efficiency can make all the difference when it comes to a team’s chance at the championship. Over the last 17 years, only one national champion didn’t finish in the top 20 for both offensive and defensive efficiency. Similarly, software teams have to rely on multiple team members including the programmers focusing on new features and fast plays, as well as the QA and operations teams ensuring that there are measures of testing and monitoring in place, so those same features aren’t released with bugs and breakages. To be successful, you need to aim for a balance of speed and quality. In DevOps, your efforts will fall short if you’re only thinking about your offensive strategy while underestimating the importance of strategic defensive plays.

Coaching is Crucial

Coaching experience has become a strong predictor of future success, as 15 of the last 17 NCAA title champions were led by a coach who had been to the Final Four previously. Similarly, leadership and management in DevOps and the transition to DevOps is paramount to creating an environment that is supportive of the necessary changes. In fact, according to a Forbes Insights and PMI survey, 85 percent of respondents said that change management is critical to their success in times of disruption. As teams attempt to speed up their processes to meet consumer demands, it’s evident that leadership is going to be a defining factor of the success of the team. Additionally, amid a cultural shift, management needs to have the right mindset to get the entire team on board, adopting new tools and practices. Just as coaching influences college basketball, experience, skill and vision all come together for transforming a team and creating a culture of DevOps.

Expect Upsets

Upsets happen—that’s the beauty of March Madness! While teams are seeded to indicate the likelihood of success in the NCAA tournament, you might think that it’s always best to pick the highest seed. But according to the NCAA, you should be aiming for around 16 upsets in your bracket. Just ask anyone who had UVA in their Final Four last year, when the No. 1 seeded team lost to 16-seed UMBC, how important it is to expect an upset. Sometimes, all your systems are perfectly in place and everything is performing as it should, and something will still break. What’s more important than aiming for perfect software delivery is having the processes in place to patch bugs, handle downtime and fix errors when they inevitably occur.

Teamwork Will Tell You Everything

There’s always talk of the star players, but success comes down to much more than one person’s free throw percentage, shooting efficiency and steal rates. Most of the statistics you look at to build your bracket revolve around teamwork—the team’s strength of schedule, the team’s winning streak, the team’s loss margin, even the measurement of explosiveness and competitiveness. None of these points can be attributed to one person; they change from season to season, and they’re all about how the entire team works together. Selection Sunday is needed every year to seed the teams because performance changes every year based on the team dynamic. Similarly, your organization will not be successful in DevOps if there is not a focus on communication, collaboration and teamwork.

The Absence of Key Players Will Trip You Up

While you can’t depend on one star player to determine the outcome of an entire team, you’ll also run into trouble if key players are out for the season. Just think: You probably wouldn’t pick Duke to win as quickly without Zion Williamson. Just the same, when there are key teams and team members missing or not committed to a changing culture, it will hinder others. There are various roles that every organization needs to succeed in DevOps, and this requires everyone to be on the same page whether you’re in development, operations, QA or are a business stakeholder. People are one of the most important parts of the transition to DevOps; if the entire team doesn’t show up, new technology and approaches won’t be able to make up for it.

There’s a strategy to everything, and it just so happens that your approach to DevOps may be similar to your approach to filling out your bracket.

By following these five pieces of advice, your software team will be more prepared to win it all when it comes to attaining a faster delivery of high-quality products.

— Alexandra McPeak

April 1, 2019
Integrating the Impactful Immersive Experience Team

Immersive: providing, involving or characterized by deep absorption or immersion in something (such as an activity or a real or artificial environment) — Merriam Webster Dictionary

We immerse a teabag into hot water to brew tea, but when we speak of the “immersive experience” we’re not planning to boil anyone. We may, however, make them feel as if they’d been boiled, or frozen, or hurtling through space, enjoying the beach or any of many other experiences. What we are really talking about are digital-based immersive experiences.

The First Immersive Experience

From July 1930 when Orson Welles first asked, “Who knows what evil lurks in the hearts of men? The Shadow knows …” or January 1933 when actor Brace Beemer first intoned, “Return with us now to those thrilling days of yesteryear, when from out of the past come the thundering hoofbeats of the great horse Silver! The Lone Ranger rides again!” radio was the first analog immersive experience.

It was immersive because the audience employed their imaginations to add imagery to the spoken word and the sound effects. While listeners knew these were fictional tales about fictional characters, they became immersed in the stories because they exhibited what poet and aesthetic philosopher Samuel Taylor Coleridge first described in 1817 as “the willing suspension of disbelief.”

Coleridge posited that if a writer could infuse a “human interest and a semblance of truth” into a fantastic tale, the reader would suspend judgment concerning the implausibility of the narrative.

Television and movies leveraged that same willingness to achieve even more immersive experiences.

While these are all examples of entertaining immersive experiences, it wasn’t long before these turned up in practical applications. As an example, astronauts learning to rocket to the heavens first experienced those travels in a flight simulator that combined film imagery and audio to create the impression that the user was actually in the rocket.

Digital Immersive Experiences

The actual word “immersive” wasn’t used much until the mid- to late-1980s, a time when Atari, Nintendo, Sega, Apple, IBM and others were busily introducing new personal computers and game consoles.

Computer-based gaming was perhaps the precursor, or even the first example, of digital immersive experiences. Players often entered a catharsis in which they perceived themselves to be existing in a fantasy world. The image quality created by the software continued to become more and more lifelike and real to enhance that perception of participation.

Now retailers are beginning to leverage immersive experience technology to help customers shop by showing them what garments might look like—on themselves. Varying colors and accessories instantly by clicking at a kiosk or computer screen.

Many training courses and support activities are leveraging immersive technologies to augment the student or practitioner experience. A technician in the field can don a headset and see the support expert’s hands showing them exactly what to do and where. NASA has astronauts walking around on a virtual Mars. Students sitting at home feel like they’re in a classroom with the instructor and other students. Peloton customers mount their home spin-cycle in their family room and participate in a class now occurring in a New York studio.

Many producers of software describe the importance of the user experience to the success of their products. Citrix, for example, designed its entire product suite around the idea that the mobile user experience should closely approximate the on-premises user experience, even though available bandwidth differed widely between the two. Today’s virtual desktop experience, which manifests in many ways, follows that design ethic. It’s worth noting that Citrix continues, to this day, to find ways to improve video and audio transmissions between the data center and the user in a constant effort to enhance the user experience.

Extending the DevOps Model

Beyond the “continuous improvement” goals of the DevOps model of computer and software management is the idea that the developers who write the code and the operators who make sure it runs well on the network infrastructure must work in concert to rapidly identify, quantify and resolve all issues.

Immersive experiences take this concept further, extending the integrated team to include not only the coders and operators, but also the artists and writers who create the written, audio and visual content and the subject matter experts who assure the veracity and integrity.

Like game developers, this extended team must work together in concert to assure that the content is appropriate, the code is efficient and the delivery is continuous, flawless and totally secure. Even the slightest latency may damage the user’s willingness to believe.

Channel Choosing

This team must also determine best practices for developing and delivering experiences through appropriate, effective and impactful channels. In the 1930s, the only vehicle was radio. In the 1940s, image was added to sound with the introduction of television. Opportunities exploded starting in 1969, with the introduction of what would become the global internet.

Today we can categorize virtual reality, augmented reality, mixed reality and more into immersive experience options. It’s one thing to have a 360-degree camera; it’s another to put it into the hands of a talented 360-degree photographer or videographer. Developers are starting to design impactfully for Oculus Rift, Microsoft HoloLens and other immersive devices.

Even the tools people use for everyday communications are becoming more immersive. Where once you could text someone, but then had to change to other software and hardware to call them, today’s unified communication solutions create a far more immersive environment. Now you can start by texting to each other, then switch to voice and/or video with a click, share applications and edit content together with a click and even add other users by click.

How to Increase Immersion

It stands to reason that the more human senses you stimulate, the more immersive the experience becomes. Adding image to sound as we moved from radio to television certainly resulted in greater audience immersion. Theaters are experimenting with combining 3-D projection with seats that move and shake in accordance with the on-screen action. Only the olfactory sense has not been treated yet, but how long can it be before the introduction of “smell-o-vision”?

Effective creation of immersive experiences requires software developers, network designers and implementers, writers, photographers, graphic layout experts, subject matter experts, social engineers and behaviorists to work together effectively. The combined creativity in a team like that will, itself, be thoroughly immersive.

— Brad Mallard

March 18, 2019
Why Hiring Top Web Developers is a Good Idea

Web developers are a great addition to every organization. Having your own web developers to help you create web applications and websites can be invaluable to companies of every size. If you happen to be a software development team, they are indispensable members of your team.

Because web developers are in such high demand, hiring the best of the best can be an extremely expensive endeavor. However, hiring them is more than worth the investment, as web development is one of the most valuable activities of any company, especially tech companies and web design agencies.

With top web developer talent, you’ll surely make more than your initial investment. Investing in quality is always a sound decision, especially for software teams, where a lack of expertise can spell doom for the end product.

Facilitating Communication

It’s good to have a team of both frontend and backend web development specialists. The top web developers can help specialists with weak points or blind spots. They can help other, less-experienced members of the team implement a piece a source code, an algorithm or a create a better-optimized database.

Premier web developers have extensive knowledge and experience with web development, which can help other members of the team better communicate their concerns with other specialists.

With an in-depth understanding of web development, they know how to translate backend issues to frontend specialists, greatly facilitating communication and collaboration.

Improving Team Morale

The best web developers aren’t only technically adept, they are also great communicators, collaborators and leaders. They know how to speak empathetically, compassionately and honestly and openly. They are active team members who voice concerns, questions and comments in a way that everyone can understand.

When communication and collaboration are facilitated and when constructive criticism is encouraged, team morale is impacted postively. When team morale is boosted, productivity increases, miscommunication decreases and passion for the project can be revitalized. Talented, team-oriented web developers can provide your team with extra motivation and much-needed mentorship.

Bringing Perspective

The top web developers have the experience necessary to bring in a fresh perspective to organizations of all sizes. The best web developers likely have worked on extensive projects for important clients, encountered a great deal of strife and come up with unique solutions to intimidating problems.

While attracting top talent isn’t an easy thing to accomplish, it is worth the time and effort it requires. Young companies, especially tech startups, can benefit from bringing experienced web developers onto their teams.

Exceptional web developers can act as managers, mentors and liaisons for young, sparsely populated companies. The most experienced web developers can inject knowledge, quality and direction to small companies.

Keeping a Consistent Pace

The best web developers maintain a consistent pace, leveraging lean and agile project management principles to do their job to the best of their ability.

One big mistake young companies commit is biting off more they can chew. It’s a good idea to keep a steady, consistent pace. If your team is using Scrum to help maintain pace with sprints and project retrospectives, experienced developers can be of great use.

Their experience can help the team establish a successful sprint schedule, helping other team members get acclimated to turning in project deliverables in a consistent and sustainable way.

Conclusion

The best web developers on the market are difficult to attract. Hiring dedicated web developers requires organizations spend the time and money carefully to find, vet and hire the best in the business.

Why are the best web developers worth the investment? They can enrich your organization with their expertise, their talent and their communication skills. It’s important to remember that the top developers are not only technically but also socially gifted. They exhibit leadership skills, easily communicating ideas and encouraging collaboration.

If your organization is looking to hire a web developer, seek out top-caliber candidates, especially if your company is young or understaffed. While you may not believe you can afford the best web developers at this junction, it’s well worth the risk to invest in them.

— Anthony Coggine

December 11, 2018
DevOps as Matrix Management

How matrix management can help teams work effectively regardless of skills

We want teams to share a common purpose. They need a wide set of skills. If we lead by purpose, then we can’t lead by skill, so how are people going to be evaluated on their professional competence? How will they grow?

Matrix management. People are led (guided in what to do) by program managers focused on shared purpose. Additionally, they participate in a professional, skill-based hierarchy where they grow in how to do their work best.

Some challenges: People can feel like they have two bosses. Professional leadership can feel like they don’t have control over the people they’re responsible to grow. Program managers don’t have full control over hiring or training, even if this team’s particular needs are unusual.

Multidisciplinary Software Teams

A complete software development team needs to take responsibility for operations, delivery, observation, security, scaling, testing, accessibility, user experience … so much! How do we add all these skills to one team? With tooling.

We abstract hardware behind an API. We build self-service spin-up tools. We make builds automatic. The professional leadership in these aspects of software are the people building these tools, whether in the same team or in Development Experience teams. These same people serve as consultants when teams need more expertise.

The product teams decide what they need to do, and these support teams help with how. When a product team has special needs, they can take more control and make their own delivery, for instance. Until then, people can learn operations at a high level, not the whole stack.

It is like matrix management, except the contributors stuck in the middle are software, not humans! They don’t mind having one team push their buttons and another change their code. The team behind the tooling feels control. For special needs, the product team is free to “hire” and train their own software.

In business, matrix management lets multidisciplinary teams share a purpose, while still helping people grow in their professional skill sets. In software, DevOps means each team changes and operates their software, with the help of continually improving automation.

— Jessica Kerr

December 6, 2018