devopsy.kinsta.cloud

Category: DevOps Culture

  • Chief Digital Officers Driving Digital Transformation

    Chief Digital Officers Driving Digital Transformation

    The chief digital officer has always been a position that has struck me as a bit awkward as part chief marketing officer and part chief information officer. Since the CDO position started gaining traction about five years ago, most industry watchers have pegged it as a temporary role that would be displaced after the urgency of the early digital transformation efforts were complete.

    The CDO being a transient position is still the prevailing view, but history has shown the popular opinion at any given time is not often the correct opinion. A survey released this week by digital services provider Mindtree found that the CDO may have more staying power than conventional wisdom suggests.

    The survey, conducted among 323 global businesses and IT professionals in the U.S. and U.K. who work under a CDO, found that 76% of respondents believe the CDO position is becoming more relevant since the role was created. Only 7% believe the CDO role is less relevant today.

    Eighty-one percent of respondents agreed that their organization likely needs a CDO. Mindtree’s survey also found that respondents believe their CDO has been effective at championing business-driving digital initiatives, including providing seamless digital experiences to customers (27%) and creating new business models (20%).

    The survey found, not so surprisingly, that at 70% of respondent organizations, their chief digital officer comes from an IT background. And of those organizations, 84% claim to have made significant digital progress since their chief digital officer took their reins. Somewhat fewer organizations (73%) whose chief digital officer came from a non-IT background cited that they have made significant digital progress.

    Still, challenges remain for CDOs if they are going to continue with their success. The survey found that about a third of organizations’ resistance to change is the largest obstacle in the way of chief digital officers, and 38% said they need to collaborate better across business units and find new digital talent in order to succeed.

    The number of enterprises with a chief digital officer has grown significantly. According to the most recent annual Harvey Nash/KPMG CIO Survey, the percentage of enterprises with a CDO rose to 48% in 2018, up from only 25% in 2017. Still, the survey showed that most of those positions (about 90%) had chief digital officers in temporary positions, with one in five choosing instead to have their CIOs perform chief digital officer duties.

    Whether or not the chief digital officer becomes a permanent corporate fixture or proves to be a bridge position, as enterprises play catch up with their digital transformation efforts, remains to be seen. But one thing is certain: the work they are doing today is vital for the long-term success of the enterprises their working for.

    — George V. Hulme

  • The Top Six Cloud Computing Trends of 2019

    The Top Six Cloud Computing Trends of 2019

    Cloud computing was one of the hottest topics in the technology and business media throughout 2019. This is no surprise as the cloud sector has been growing rapidly for the last few years. Synergy Research Group recently reported a 37% overall growth year-over-year in public cloud. They also note that it has taken just two years for the public IaaS and PaaS markets to double in size and their forecast shows them doubling again within the next three years.

    While steady growth was expected this year, a few trends of note stand out. When the experts look back at 2019, they will likely stress the following cloud computing trends shaped the year.

    Rise of the Enterprise Cloud Manager

    We recently did a study on ParkMyCloud users which showed that a growing proportion of company technical leads have cloud or the name of their cloud provider–such as AWS–in their job title. This indicates a growing degree of specialization for individuals who manage and architect cloud infrastructure. Whether called enterprise cloud manager, cloud architect or something similar, 2019 saw the rise of a specialized role to oversee and direct cloud operations.

    Consolidated Multi-Cloud Views

    As enterprises large and small continue to adopt and use more than one public cloud, we have seen a rapidly growing need for a consolidated multi-cloud view and ability to take actions across multiple clouds in 2019. Third-party tools that do this provide enterprises the ability to pick a single tool to orchestrate, manage, govern and optimize their hybrid and multi-cloud environments. Many customers also sight the need to simplify operations—native cloud provider tools are not always easy to use.

    Multi-Cloud Arrives

    Multi-cloud truly arrived in 2019 and will only grow in 2020. The majority of organizations now use multiple clouds. In fact, most studies suggest that more than 80% of enterprises have a multi-cloud strategy. Reasons cited include the need to avoid vendor lock-in, the ability to leverage the best in class cloud services from each cloud provider and application efficiency choices.

    More Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down operations and critical projects. Thus, the trend toward automation continued to expand in 2019.

    More Abstraction

    IT became more and more abstracted in 2019. This means container usage grew, along with models that allow developers to worry less and less about infrastructure (such as serverless and PaaS).

    Containers Became Mainstream

    Application containerization is more than just a new buzzword in cloud computing; it is changing the way in which resources are deployed into the cloud. More and more companies utilize container services such as Kubernetes and cloud native services such as EKS, AKS and GKS in 2019, 

    Business continued to move to the cloud in 2019 and the six trends described above showed that the sector is growing–sometimes in unpredictable ways. Next year will, no doubt, also contain some surprises. But the trend for expansion of the cloud and related services is unmistakable for the foreseeable future.

    — Jay Chapel

  • Predictions 2020: How to Make the Case for Adopting CI/CD in Your Organization

    Predictions 2020: How to Make the Case for Adopting CI/CD in Your Organization

    The practice of continuous integration and continuous delivery (CI/CD) is fundamental to modern software development. And yet, many organizations are still using slow, error-prone, manual processes to build, test and deploy their software. Sometimes, the blocker can be engineers who don’t want to change how they’ve always done things, but most often folks in the trenches are chomping at the bit to automate. All too frequently, it is IT leadership and executives who need to be convinced that making a large investment in updating tools, training and culture will net returns greater than the cost.

    If you want to change management’s mind about an investment in CI/CD, focus on making a strong business case. This may sound daunting, but it’s easier than you think. Learning a bit about how to advocate for budget and organizational change can go a long way. Just think about what life would be like if, instead of sitting in endless change management meetings, you could get your code to production simply by merging to master while automation takes care of the rest.

    This article will get you started with some concrete tips you can use to get CI/CD green-lit by your leadership.

    Start Small

    Agile and DevOps are all about breaking things up into smaller chunks. It may seem counterintuitive, but deploying more frequently equates to less risk because small changes are easier to orchestrate, troubleshoot and roll back than large complicated deployments. In that same way, you can reduce the risk to the organization by taking a DevOps approach to transformation. Rather than trying to upend your entire process, see how you can break the change up into small, iterative chunks.

    Almost every large enterprise that has successfully adopted wide-spread CI/CD started with one lighthouse team. Changing everything is a tough sell. Instead, approach management with a low-risk proposal: “We’d like to run an experiment to see if we can deliver more quickly and reduce costs. We have one team that will take one small project and test CI/CD automation to see what the results will be. We can leverage open source tooling to get started at a low cost.” Even the most stingy budget holder should find the proposal intriguing.

    Measure the Results

    Once you’ve started to conduct your experiment, it’s important to measure what you observe. What are the differences between the old way and the new way? The more concretely you can quantify it, the better. Saying, “We went faster,” doesn’t carry a lot of weight. But if you can quantify it, your message becomes more potent. For example, “Our previous cycle time from the moment a developer begins work on a ticket to the time that code is running in production and useable was 30 days. By automating some of our manual efforts using CI/CD we have cut that to five days.”

    For this part of the process there’s no need for exact numbers. Most likely if you aren’t doing CI/CD today, you likely don’t have the instrumentation in place to accurately measure cycle time. But don’t let that be a blocker. You can give estimates. “From about one month to one week,” is still a powerful story.

    Some other metrics to capture that can help make your case are:

    • Number of tests run.
    • Code coverage in terms of percentage of code tested.
    • Number of people-hours required.
    • Number of defects in production or number of regressions/roll backs needed.
    • Mean time to repair (MTTR): The average time from when a bug/failure is discovered in production to when the fix is running.
    • Frequency of releases—how often new capabilities are available for users.
    • Cost to deploy: This is a very powerful metric if you can estimate it. A good rule of thumb is: (number of people minus hours, times average hourly rate) plus (cost of assets and services required).

    Aim to use three to five metrics to prove your case. You don’t want to overwhelm with data. The point is to show that things are better with CI/CD, not that you’ve gathered a lot of numbers. Use a simple before-and-after format to show the change. State the changes in terms of increased value, reduced cost and/or reduced risk. For example, “We increased value for our users by shipping 10 times more features in the same time frame, reduced deployment costs by 80% and reduced risk by increasing code coverage by 30 points from 40% to 70%.” 

    Couple Your Efforts to Business Outcomes

    A critical element of IT success is how closely you can partner with the business. It can be next to impossible to get initiatives green-lit if the only benefit is to make things better for IT. But if you can show how some extra effort spent on IT modernization can drive results for the business, then you’ll find you start getting enthusiastic approval from leadership.

    Collaborating with people outside of IT or software R&D is a career-enhancing skill every technical practitioner should strive to improve. 

    Get to know what efforts in sales, marketing and product are dependent on IT. For example, the sales department may desperately need additional capabilities in their forecasting tool if they are going to execute strategic deal acceleration, ensure quarterly numbers are consistent and avoid unpredictability with shareholders. In other words, the fact that your slow delivery cycle can’t get those new features on the release calendar for another three months is putting the stock price in jeopardy.

    To avoid this tragedy, you can tie your CI/CD efforts to the sales outcomes. By getting to know the pain points of your sales colleagues, you can craft a powerhouse “ask” to leadership. “We’d like implement CI/CD to automate deployments for our sales data management system. This will allow us to implement new filters in a matter of days rather than months which sales needs to hit their numbers.” 

    Pulling It All Together 

    It can be demoralizing to feel like you are behind the curve. Looking at other businesses who have already adopted CI/CD it can feel like you might never catch up. If this is the case, some axioms are appropriate, such as the famous Chinese proverb from the Tao Te Ching “A journey of a thousand miles begins with a single step.” And as Theodore Roosevelt said, “Comparison is the thief of joy.”

    The reality is that you are not alone. Many organizations, especially large enterprises, are relying on outdated software practices. Convincing leadership to green-light IT modernization efforts can be a challenge. Adopting CI/CD in a meaningful way does require significant investment, but there is a lot you can do to smooth the path for them and earn their support.

    Begin by identifying a small adventurous team who can serve as an experimental testing grounds. Not only will their success help to convince leadership, but their example serves to light the way for other teams to adopt DevOps. Identify metrics you want to capture and be sure to instrument so you can measure the improvement. Pick a few metrics that show increase in value, decrease in cost and decrease in risk. Finally, reach across the org to collaborate with your non-engineering peers. By showing how your modernization effort drives outcomes for the business you’ll be sure to earn respect as well as additional budget to expand your CI/CD efforts.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — William Chia

  • Untapping the Potential of DevOps, Part 3: Keys to Success

    Untapping the Potential of DevOps, Part 3: Keys to Success

    Over the course of this series, we’ve talked about some of the common mistakes we have seen organizations make as they either launch or continue their journey into the world of DevOps. But just as it is important to understand the pitfalls that may happen during a DevOps transformation, it is perhaps even more important to know what the key indicators are that drive success. With that in mind, here are a few tried-and-true tactics for making the most out of your DevOps initiatives.

    Start With Automation

    One of the most powerful areas of impact for DevOps is in driving automation. It accomplishes several things: it increases the velocity of the development pipeline, it can reduce the number of errors or potential errors in code and it often frees up time for developers, allowing them to focus more on creating value and less on repeatable and mundane tasks. By ensuring that DevOps automation goals, including CI/CD, test automation, monitoring, Infrastructure as Code and GitOps are included at the outset of projects, you can better set up your organization for successful software development and delivery—both in the short term and for the long haul.

    Strong Communication

    When it’s all boiled down, DevOps is like any other advanced business tactic as it relies on strong communication to deliver the most success. As the name implies, DevOps engineers must bridge the worlds of development and operations, so to be truly effective they need to possess fluency in both worlds. Can you have success if you have engineers who are only strong on one side of the equation? Technically, yes. But you will not maximize the amount of value from your DevOps initiatives without stakeholders who can adeptly manage both sides. Additionally, communication with the business and other non-technical sides of the organization is critical. The entire organization should be on board with DevOps, with clear visibility into the transformation—your successes and challenges will come from frequent, effective communication.

    Adhere to Processes

    DevOps is process-driven, particularly as organizations scale. To work effectively, and to serve real enterprise environments, creating and adhering to processes is key. While automation is important for the rapid delivery of value, effective change management is important for sustainable development and system operations. Process and compliance are an important part of sustainability for large environments. It is also extremely important for organizations where compliance is vital—think industries such as finance, medical and government. By implementing and adhering to well-defined processes, you can avoid future headaches or rework that will slow down the pipeline.

    Leadership Buy-in

    The most impactful changes have one thing in common: strong leadership. Leadership dedicated to delivering customer value and understanding the software’s prominent role in delivering that value is key. Organizations that cling to outdated methods of development and delivery (i.e. waterfall) lead to slower delivery of value, which is the ticket to extinction. DevOps also benefits greatly from having leaders within the organization who serve as champions for change. By keeping a finger on the pulse of your organization from within, you can better practice change management, identify potential weaknesses earlier on and make your DevOps initiatives work for you.

    DevOps can be an extremely effective way to deliver the most customer value from your software pipeline. By keeping these four key indicators in mind, you can better position your team for success and enjoy the benefits of your DevOps journey.

    — Jonathan Fries

  • Infrastructure as Code and Six Key Automation Concepts

    Infrastructure as Code and Six Key Automation Concepts

    This summer, I walked into an Infrastructure as Code (IaC) flame war because I was blissfully unaware of just how broadly IaC had been reinterpreted. Reviewing the comments, it’s clear that thinking has evolved since Kief Morris’ 2016 Infrastructure as Code tomb. So, after strapping on my asbestos suit, I decided to dig into what is creating such a wide range of opinions and see if I can share some 2019 insights.

    Why does IaC provoke such passion? The reason is simple: As an industry, we aspire to something that delivers on our collective vision of fully-automated, self-governing infrastructure. In the 00s we called it autonomic computing, then software defined data center (SDDC) and, now, IaC. Sadly, IaC is not it—or, more specifically, it’s not it alone.

    The actual definition of IaC is way smaller than what people want it to be.

    My take-away from IaC discussions is they are built around six key automation themes. Let’s take a few minutes to examine each of the themes. Then we’ll have a basis for answering “If that’s not IaC, then what is it?”

    Programmatic Configuration (IaC)

    Programmatic configuration captures the idea that we can define our infrastructure in a machine readable format. For example, you describe a planned cluster build in YAML to execution by a tool such as Terraform that requests the resources from your dynamic infrastructure and, hopefully, tracks that resource descriptors you get back from that request. Basically, it’s just your IaaS input format.

    Dynamic Infrastructure (or IaaS)

    It describes a system that allows operators to change the resource allocations via an API. It’s a critical part of the discussion because there must be a dependable way to pragmatically change the infrastructure. Some would consider this cloud; however, we should not assumes either managed services or VMs because dynamic infrastructure is much broader.

    Desired State (or State Reconciler)

    Desired state actively compares dynamic infrastructure to programmatic manifest and makes automatic adjustments to keep them synchronized. Typically, the idea of maintaining state is separated from configuring systems. Kubernetes and other Autoscaling cluster managers perform this role.

    Deployment from Source Control (or Immutability)

    It implies that all of the configuration components of the system can be stored as versioned artifacts and deployed from source. A Dockerfile that builds a container is a good example of an immutable process and the generated artifact. The repeatability offered by deploying from source control is transformative compared to past generations of operations that relied on either manual or scripted changes to production systems. Immutability is not IaC: We are focused on an generated deployment artifact rather than managing the infrastructure.

    Composable (or Modular) Automation

    It allows us to manage complex structures through layers of abstraction. In concept, composability is as simple as using platform plugin to script against an API.

    CI/CD Pipeline

    CI/CD pipeline is the glue that pulls all these pieces together to create a resilient environment by continuously adjusting the system components based on the operators’ IaC descriptions. The pipeline relies on having dynamic infrastructure managed to desired state as a target; however, it adds the critical concepts of staged changes over time to the system. Since we need to create systems that can adapt and improve over time, the CI/CD pipeline provides mechanism for controlled implementation change over time.

    Together, these six concepts reflect an integrated new way to think about the infrastructure that is beyond IaC. They allow us to maintain and control our systems over time in a way that is resilient and automatic. More importantly, they bring complex infrastructure problems back into terms that people can comprehend by creating more deterministic and predictable chains of change. That allows us to keep our hands out of the infrastructure and our minds focused on what we are delivering: a continuously integrated data center.

    Since all six concepts are interdependent, continuously integrated data center (CI DC) completely captures our aspirations for IaC. The term intuitively builds from source code into a fully operational infrastructure. More importantly, CI DC demands that we acknowledge the ongoing maintenance required. For that reason, I’ve embraced CI DC to replace IaC.

    Does the term work for you? How do you see IaC or CI DC being delivered in 2020? I’d like to hear your thoughts.

    — Rob Hirschfeld

  • Why Is Security Missing in Many DevOps Implementations?

    Why Is Security Missing in Many DevOps Implementations?

    The exceptional and ground-breaking, technology-driven opportunities in today’s digitized age come with significant competitive pressures to transform promptly. Specific demands increase due to continuous repeating in response to customer preferences becomes the more deep-seated expectation. To overcome this issue, organizations are shifting toward DevOps as a medium to deliver innovations quickly.

    DevOps also promotes innovation and agile software development but, for optimal results, proper security implementation is required. When business security teams are more cohesive in the development culture it is easier to secure new developments from the start. 

    DevOps is all related to automation and speed. At times this can make the apps in development get exposed to malicious attacks, which results in various scams. However, the end customer is seriously concerned about the security feature. The tools you’re going to choose might be vulnerable to different security issues. Hence, it is essential to select those tools that comply with security concerns, such as the General Data Protection Regulation (GDPR).

    DevOps culture is driven by moving fast yet in small pieces. It offers organizations with a wide range of benefits, which includes cooperation among stakeholders, development processes, improvements in code quality, as well as enhanced business velocity. 

    DevOps is responsible for solving different challenges in the software development process, but at the same time, it also familiarizes new challenges. It is found that less than 46% of IT experts are neglecting security in DevOps design and planning. Such environments end up with an inactive and uncoordinated approach to incident management and mitigation.

    There are several reasons for security being missed during DevOps implementation. Some of them are discussed below.

    Cultural Resistance to Security

    It is a standard view in many organizations that introducing security will lead to a slower development process. However, the overall effort and time cost of catching some security flaws early in the design or development process is much lower than to fix the problematic code and weaknesses later during the development cycle. 

    More Focus on Speed Than Security Teams

    DevOps teams are often associated with InfoSec teams. DevOps induces and modifies code batches over a short period, which might far outpace the speed at which the security teams can keep up with code review. If security—code analysis, configuration checks and vulnerability scanning—is not adequately automated, the DevOps output will eventually be slowed down or result in a lack of security hygiene. 

    Practically, this fallout consists of insecure codes, inadvertent vulnerabilities, hard-coded passwords, misconfigurations and other weakness in-app security that can contribute to operational dysfunction or get exploited by attackers.

    DevOps and Cloud Environment

    A typical DevOps environment is dependent upon cloud deployments, which often shares many cloud security considerations. DevOps teams influence the latest, open-source and even immature tools to manage various security groups and server instances. In this digital age that function at large scale, a slight misconfiguration error or security malpractice can be widely propagated, resulting in extensive operational dysfunction or other exploitable compliance and security issues.

    Poorly Managed Access Controls

    Most of the aspects of DevOps are interconnected, changing rapidly and utilizing secrets. DevOps secrets might include private account credentials, APIs token, SSH Keys, etc. that might be used by both humans and non-humans, for example, apps, containers, cloud instances and microservices. Ineffective secrets management is a common flaw in DevOps environments. It provides a provoking possibility for attackers to interfere with the security and other controls, disrupts functions, steals information and exploit an organization’s IT infrastructure. 

    Moreover, to further advance the workflows, DevOps teams might also allow unrestricted access to some private accounts by multiple individuals, who might share their credentials. This is a practice that eliminates the chances of a clear audit trail. Several methods, configuration management, as well as other DevOps tools, might be granted immense privileges. With access to private accounts, an attacker or even a piece of malware can get full control of the data and systems.

    Security should be a top priority of an organization while implementing DevOps, but due to the practices mentioned above it is often neglected.

    How to Ensure Security in DevOps?

    Sticking to security helps the team to come up with quality code. This practice makes developers write error-free codes. When this culture turns into a norm, it fosters the DevOps efforts as a whole. Below are some of the ways to ensure security in DevOps:

    • Set a priority list and put things according to it. Shift the security focus to the left in the development lifecycle.
    • Ensure that developers are well aware of the security consequences and principles and follow the same path as of yours.
    • Educate and train your developers to use particular tools to build secure systems, as well as also keep your DevOps system safe.
    • Set up an alerting and monitoring system to avoid any damage in the end. 
    • Do have proper metrics and submit reports daily to ensure that everything is under control.
    • Various compliance tools and the best business security systems should be introduced into the toolchains. If the codes fail to pass security tests, the build breaks and does not gets deployed so, sent it back to the developer for further refining.
    • Adopt different configuration managements. It means do scans to identify and remediate possible errors. Stabilize all configurations by using the industry’s best practices. Also, allow continuous configuration and hardening baseline scanning across various servers and codes which are built for cloud assets.
    • Do prioritize the deployment of automated tools to detect possible threats, problematic or vulnerable codes and other issues with process and infrastructure. More strictly, you will match the speed of security to the DevOps process; the less you’re going to come across culture resistance, which is embedded in the security practices.
    • Shift toward the rising trend of DevSecOps. It is a practice of injecting security in the lifecycle of app development. It reduces vulnerabilities and brings security much closer to business goals.

    Final Thoughts

    Security is a crucial element in DevOps implementation because it influences the bottom line of any organization. At times, security is missed out, but if this continues it will eventually lead to exploitation by hackers and loss in customer trust. Remember, everything can be recovered, but once a customer’s trust is lost, it can never be gained again. Thus, it is imperative to ensure security while implementing DevOps and achieve success by leaps and bounds.

    — Farwa Sajjad

  • Emerging Patterns in SRE Implementation

    Emerging Patterns in SRE Implementation

    First we were told that every company will become a technology company. Then the tides shifted to every company will become a DevOps company. Now the zeitgeist has a new obsession: Every company will become a Site Reliability Engineering (SRE) company.

    Have you been keeping pace? If your company survived the ruthless restructuring of digital transformation and is savvy enough to have surfed the DevOps wave, you might already have heard SRE is the next industry standard on the horizon. And you might be bracing yourself for yet another cycle of emerging best practices. Is the dread setting in?

    Fear not, throwing out the welcome mat for SRE does not require kicking DevOps to the curb. On the contrary, the two are complementary philosophies, which, when harnessed correctly, can usher in a new era of value delivery. Essentially, SRE is a specific implementation of the core DevOps pillars of success that applies a software engineering mindset toward solving traditional operations problems–with a focus on creating reliable and scalable technology. Together, DevOps and SRE work in harmony, striving toward a shared goal of breaking down organizational barriers and delivering better software faster. 

    If you’re ready to give SRE a shot but you are unsure how it best fits within your team’s existing structure, let’s break down the top five team organizational structures that emerge with clients. However, feel free to view these as loose guidelines rather than an exact blueprint. Similar to DevOps, there are diverging views and practices of integrating SRE into a company’s structure.

    Discovering the unique way SRE fits into your team is the most rewarding and fun part of adopting this new system. What matters most here are outcomes. Creating a role for SRE means alleviating some of the pressure on your developers, allowing them to be more productive, and more efficiently and effectively implement the DevOps paradigm. Soon enough you’ll be reaping the benefits of what happens when, as Ben Treynor, Google vice president of engineering said, “a software engineer is tasked with what used to be called operations.”

    The OG(oogle)

    Let’s give credit where it’s due. We wouldn’t have the SRE acronym, let alone the entire discipline, if it weren’t for Google’s innovative ops team. With the aim of bridging the gap between its production and ops teams, Google ops leader, Ben Treynor proposed eschewing the norm of building an ops team solely from system administrators and instead bringing in software engineers who possessed a systems background.

    This model entails creating a dedicated engineering team focused on running and scaling a product or platform. The team should be comprised of highly skilled software and systems engineers who are on-call for the product, and simultaneously directly updating the product code base for reliability and building associated tooling to support the product. Most importantly, the product development team is still responsible for a portion of these operational tasks and may not be allowed to ship new features if reliability falls below agreed upon thresholds (the Error Budget).

    Why Change When You Can Rebrand?

    If your ops, DevOps and platform teams are on board with the SRE philosophy but you either don’t want or don’t need to make significant changes to your product code, this is the approach for you. In this model, your teams can simply rebrand as Site Reliability Engineers, while adopting and implementing the tenets that come with the title. That means shifting the concentration of engineering to focus on improving reliability and scalability. This team would also be on-call, playing a prominent role in the underlying infrastructure, tooling, platforms or day to day support of the product.

    Beware: You need to take seriously the underlying tenets and need for strong software engineering skills on these teams in order to realize the benefits.

    The Inside Job

    Perhaps you’re down with SRE but don’t want it to co-mingle with product accountability. A viable option then would be creating an internal consulting arm–a centralized team solely dedicated to creating and advocating for reliability tools and processes. One of the prominent benefits of this structure is that your team would be able to not only see the forest for the trees but also serve as your SRE gurus, keeping your team abreast of the latest technologies, trends and research in the SRE space. 

    You Get an SRE Engineer!

    For those who want to weave in SRE engineers throughout their entire organization, this approach applies a holistic mindset to the SRE implementation proposition. That means SRE engineers are introduced into cross-functional teams that own the end-to-end lifecycle of a product, from build through decommissioning. From here the road diverges: your choice is to either create an SRE team of engineers who belong to a single capability and are also embedded full time within a product team, or allow product teams to hire their own dedicated SRE engineers. As Cloud and SRE Practice Lead at Slalom Build, I took the former. For us, this approach guarantees bespoke SRE implementation, ensuring right-sized scalability and reliability throughout the product lifecycle.

    SRE? New to Me

    Despite the compounding hype around SRE, it has yet to hit universal name-recognition. If it’s still unfamiliar to you, that’s okay. It’s not too late to raise your hand and get up to speed during this period in which we are still in the early stages of adoption. I assure you that if you reach out to expand your knowledge of SRE and even bring it back to your team, you will be met with enthusiasm and welcoming arms.

    — Rob Cummings

  • How Can IT Admins Maintain a Grip on Secure Access?

    How Can IT Admins Maintain a Grip on Secure Access?

    Today’s IT environment is evolving at a rapid pace, requiring production environments to be highly scalable and elastic and requiring faster software release cycles and cloud adoption.

    As a result, there’s a broad move toward Docker containers to make software deployment faster, easier and more consistent across computing environments. Bundling an application and its supporting code, libraries, settings and assets into a single container enables the speed and flexibility that today’s business environment demands.

    At the same time, many large enterprises are also experimenting with creating internal startups, or labs, that are given latitude to innovate, housed under the company umbrella and resources. Similarly, some companies are hosting startup-like “innovation incubators,” where developers are empowered to think and work like startups, within the relative safety of the corporate environment. They can quickly test new ideas, using the “fail fast, succeed fast” startup mentality, without incurring the usual risks of an independent startup.

    It’s a new agile way of working that companies, in the race to innovate, are widely embracing. In fact, more than half of Fortune 500 companies have some version of these startup-like efforts housed within at least one business unit. 

    Replicating the unstructured movement of a small–say, six-person–startup is difficult to do within an enterprise environment. Nevertheless, the rapid pace, combined with the flexibility to innovate, is what the vast majority of developers desire today. But, it does mean that enterprises’ IT environments have to be ready to adapt.

    IT Administrators Under Pressure

    Developers on these innovation teams are often given the freedom to select the tools they’d like to work with. That can–and often does–include Docker containers, which adds to the complexity of the IT environment. 

    The environment that fuels developer innovation also creates additional concerns for the IT administrators supporting them. Developers can work so rapidly–creating hundreds of new servers each day–but often only do the bare minimum in terms of security. How can IT admins maintain secure access in the face of these changes? How can they keep track of who has access to what application and what data, when those applications and data are constantly changing? That’s a massive issue when it comes to compliance.

    As containers make enterprise IT environments even more complex, IT admins are under pressure to carefully manage access without slowing down development. The more complex the environment becomes, the more important it will be to have a holistic view of all of their underlying infrastructure, including the hybrid or multi-cloud environments that support platforms such as Docker and Kubernetes.

    Meanwhile, the enterprise executive team, often the CISO, overseeing both the development and IT departments is hard at work trying to satisfy the requirements of both groups. Of course, it’s in the business’s best interest to innovate and explore. But, all that innovation means nothing if the business is no longer secure and open to compliance concerns.

    Below are three steps executives should follow in order to keep their developers and IT admins happy.

    Consider the Developer Experience for Secure Access

    Off-the-shelf single sign-on solutions (SSO) may be good enough for business employees who need to access Outlook or Salesforce, but they aren’t robust enough for privileged IT users, like developers, who need to access secure environments. 

    Privileged access management (PAM) software sprung up to serve IT users, but even this isn’t a perfect solution, because traditional PAM tools are often too clunky to use, nonintuitive, or hard to configure. A bad user experience simply encourages developers to bypass PAM however they can, which is a compliance risk.

    Businesses need a way to deploy secure access very quickly, so they can holistically manage access to critical IT resources without slowing down development. That means choosing secure access solutions that are built with the developer’s needs in mind.

    Lean PAM solutions prioritize automated, instant access to secure IT environments with the click of a button, combining the convenience of modern SSO solutions with the security and fit of a PAM solution. If sysadmins have a great PAM user experience, they’re more likely to play by the rules. 

    Opt for Role-Based, Time-Bound Access

    To maintain the highest levels of security, access must be controlled on a role-by-role basis. Your rock-star in-house developers should be able to quickly spin up access to core IT infrastructure whenever they need it, while a third-party development contractor should only have limited access to those same resources for the time in which they are working in your environment–and no longer than that. 

    This is where we begin to see time-limited, credential-less secure access, enabled by ephemeral certificates, start to play a role in privileged access management. Ephemeral certificates are short-lived access tokens that are automatically generated and automatically expire–so access is granted only for as long as it is needed to authenticate and authorize privileged connections. 

    In other words, privileged access is able to move toward a just-in-time model, eliminating the need for passwords and clumsy credential management. IT users no longer need to authenticate using credentials at all–instead, based on predefined roles and security policies, they are granted access to resources only as and when required.

    Ultimately, ephemeral certificates help streamline access processes, ensuring that IT admins don’t have to worry about revoking access when access roles or needs change.

    Make It Easy on the IT Admin, Too

    Speaking of IT admins, it’s important to consider their experience, too.

    Admins want to give staff the best tools for the job without compromising corporate security. The friction between admins and developers begins when the developers feel that the tools admins force them to use are slowing down their work. In reaction, admins become frustrated when more unmanaged, unmonitored tools enter the corporate network, requiring more of their time to implement, configure or remediate if something has gone wrong.

    The right technology solutions make life easier for IT admins, too. That means secure access solutions that can be installed and deployed within a single day–not weeks–and that introduce automated routines and maintenance to eliminate manual work in the access management process. Accountability, in the form of session monitoring and logging, is also important. 

    Ultimately, it’s about giving IT admins some distance. They can retain the oversight they need to feel comfortable about organizational security, without needing to be on top of every single secure access decision in the organization. At the same time, developers retain the autonomy they need to work quickly without feeling like they’ve got someone looking over their shoulder. 

    By enabling rapid development, while keeping a watchful eye on enterprise security, enterprises can satisfy both their developers and IT admins, and ultimately, the business’s bottom line.

    — Markku Rossi

  • Can We Do Without DevOps?

    Can We Do Without DevOps?

    Recently, DevOps has received so much hype and every respectable company sees it as its duty to have a DevOps team on and running. It is considered to be so beneficial to any company that a non-technician scrolling down posts at any tech website would think of it as a universal remedy for all the corporate diseases ever possible. However, given that a definition of DevOps varies from company to company and no one exactly knows what a true DevOps team should do, isn’t there some misconception between the praise that DevOps has been receiving and the real output? Let’s dig deeper and decide for ourselves.

    Yet, despite the buzz around the notion, DevOps is said to be a working thing. It guarantees a company-adopter 200 times more frequent deployments, 24 times faster recovery and three times lower change failure rates, according to Puppet’s State of DevOps Report.

    That is why, to get a non-biased view on why one should “DevOps-ize” corporate processes, in our article we give the answers to the following:

    • What DevOps is?
    • What issues is it supposed to help resolve?
    • What does a DevOps engineer do?
    • What skills does a DevOps engineer need?

    All of these questions, when answered, will help us see why the industry has adopted DevOps as a regular practice, why your company needs to try it out and why we can’t do without it the way we used to before—or can we?

    What Is DevOps?

    According to the AWS, DevOps is the combination of cultural philosophies, practices and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. Well, this definition may not be as clear as the waters of Sardinia, so we’ll clear it up for you a little bit.

    The message is that once (before DevOps) the product release was slow and troublesome, while today, with DevOps practices in place, it almost reaches cosmic speeds and high-end quality. All through maturation of work approaches and practices–merge of development and operations–along with the automation, cloud technologies, virtualization and abundance of top-notch tools. DevOps culture to a certain extent enables developers to perform the work of the IT team, and vice versa, which breaks down the operational walls between the teams, eroding a “not my task” mindset at the same time.

    What Does a DevOps Engineer Do?

    If that’s what is happening today–programmers deal with the configuration issues and the IT teams code–why is a DevOps engineer on the tip of everyone’s tongue? Why come up with a new term if you can write some more new responsibilities into the dev’s/IT guy’s contract and leave the names as they are? The thing is, the transformation of the processes and roles was so substantial, that in time they merged into a completely new position, which is neither a coding IT guy, nor a configuring developer.

    Roles Before DevOps

    Developers

    • Built features, tried to merge separate pieces of code together (usually resulted in a huge amount of errors and ended up in a long and troublesome integration).

    Integrators or Production Facilitators

    • Known to have been engaged on huge banking/insurance projects.
    • The phenomenon had a limited application within the industry and this intermediary work piece was often shared between the devs and ops with varying success.

    IT/Operations

    • Fixed the developers’ mess and squeezed the available code (often requiring a lot of massaging) into the available infrastructure.
    • Supported tech life in the offices (repairs, tech support, configuration and security, etc.).

    Roles Today, Approximate Responsibilities Breakdown

    Developers

    • Specification-based code production.
    • Software components integration.
    • Troubleshoot, debug and upgrade of existing software.
    • Creation of technical documentation for reference and reporting.
    • Integrations implementation.

    DevOps Engineer

    • Infrastructure planning, testing and development.
    • Integrations implementation.
    • Updates and fixes.
    • Build tools to minimize errors and improve customer experience.
    • Develop software to integrate with internal back-end systems.
    • Production errors root cause analysis,
    • Investigation and resolution of technical issues, Level 2 tech support.
    • Script development to automate visualization.
    • Procedure design for system troubleshooting and maintenance.

    IT/Operations

    • Install and configure computer hardware, software, systems, networks, printers and scanners.
    • Monitor and maintain computer systems and networks.
    • Service issues and requests.
    • Technical support across the company.
    • Set up accounts for new users.
    • Repair and replace equipment as necessary.

    To sum it all up, a DevOps engineer is a so-called “centaur” performing duties of a system administrator between coding sessions. His/her primary objective of the project is to find a solution that will make product deployment fast and efficient and people’s (devs and ops) lives easier.

    What Skills Does a DevOps Engineer Need?

    According to the Qulix’ practice, an ideal skillset for a DevOps is:

    • A technical graduate.
    • Intermediate or advanced English.
    • General programming skills.
    • Proficient PC-user knowledgeable about networking, Git, Linux, Docker, Nginx, Bash.
    • Strive for constant perfection and thirst for the new.
    • Curios, with inner drive to get to the bottom line, enthusiastic.
    • Strong work ethic and time management skills.
    • Open and a great team player.

    These will do for a start. At the same time, within the same company various departments may require from their DevOps engineers to have a command of different technologies. For example, another department of ours expects from their candidates to know TCPIP, DNS, Nginx, Tomcat, Git, Bash, Groovy, Ansible, Docker, Ubuntu, Debian, Macos, Gradle, Maven, CI/CD.

    As you can see, an ideal fit for the position of a DevOps engineer within a specific department is something rare. All because DevOps engineers have to have so much on their plate, both from technical and soft skills perspective. Why? First of all, as a system administrator to a certain degree, a DevOps engineer has to operate numerous technologies, that sometimes far outweigh the number of those a regular developer uses on a daily basis. In this connection, I once asked a friend of mine working in a DevOps team, “Of all the difficult things that you have to deal with as a DevOps guy, which one is the most difficult one?” And his response was “Everything.” 

    The “everything” of my friend needed further explanations, for which I headed to another DevOps engineer of Qulix Systems, Denis Golovnev. He told me he opted for a DevOps position because he wanted to get to know the whole SDLC closer and in depth, as “this position requires a 360-degree knowledge of the SDLC processes.” DevOps guys are among those few specialists who stay on the project from start to finish, to maintenance. That is why “a DevOps engineer won’t only have to dig deeper into his/her own area of knowledge, but also target adjacent spheres to see how the product is created and how his/her actions can create more value for the client,” explained Golovnev. Thus, this made the tech part clear to me.

    What about soft skills?

    “The most difficult thing about DevOps is to arrange the processes in a manner that will suit everyone; the one that will encourage the initiative and individual decision-making process, to a reasonable extent,” said Golovnev. “To achieve that, highly developed soft skills are a must to get to the root of the problem and enable an engineer to outline clearly his/her point of view to everyone.”

    On the other hand, DevOps team will inevitably face both technical and organizational issues, which should not be confused.

    “One should not try to settle human-related issues through technical means,” said Golovnev. This is another reason why a candidate without highly developed soft skills is very unlikely to get the position. Soft skills are the absolute killer thing for a DevOps candidate.

    To Wrap It Up

    We’ve been gradually migrating from slow and troublesome product releases and delivery of separate work chunks to a speedy, orderly and consistent performance. Most definitely, this transition isn’t the consequence of DevOps practices implementation alone. But without it, without the culture of speedy collaborative delivery, dynamic issues resolution and ultimate automation, which are typical of the DevOps philosophy, the shift would be impossible.

    Furthermore, the revolution starts from minds, whereas the means comes later. If a typical DevOps engineer is, as according to Golovnev, “the one in love with his/her job, insane as to automate everything within his/her reach, get to the core of any constrain that impedes fast product delivery or reduces effectiveness,” no wonder we, as consumers, and the whole industry need them. Together with the outstanding tools and technologies, a DevOps engineer is a soldier that, in 100% of cases, shoots to kill (any production constraint).

    One issue, however, remains unclear. With all the variances as to what true DevOps means even within the same company, how will we reach a unified DevOps definition? Most definitely, some unanimity would be useful for the candidates that try to land the position but end up rejected due to the above-mentioned differences in DevOps visions among the companies.

    On the other hand, lack of unambiguity is justified due to a wide range of technologies as well as different approaches used by different companies. So far, skillset variance will stay a key problem in regards to DevOps hiring. Although our main question–can we do without DevOps?–is out of the question.

    — Veronica Chizh

  • The Next Frontier for Enterprises: Moving to a Product IT Operating Model

    The Next Frontier for Enterprises: Moving to a Product IT Operating Model

    In the world of technology, there are few things as dramatic and impactful as enterprise IT’s recent ascent from an enabler to a strategic business driver. Tasked with powering next-gen digital business models, IT teams today are fast realizing the harsh truth that they must make a pervasive strategic shift from traditional project-based operating model to a product-centric one. 

    Traditional project-based operating models focus resources on a specific application or project, leading to fragmented experiences and a disconnect with the rest of the IT organization or company. For instance, in many cases, one team may be working on a back-end system, while entirely different teams work on the front-end application or updating databases. A product-based operating model takes a more holistic approach to ensure projects are integrated and teams work concurrently toward a uniform goal. 

    The days of plan/build/run are numbered as digitization forces IT leaders to act fast, think outside the norm and embrace the blurring boundaries between the digital and physical worlds. A product-centric operating model, sometimes also referred to as a DevOps operating model, accelerates organization-wide digital transformation and consolidates a business’ competitive standing. Companies must transition to a product-centric model to scale-up their agile programs to support end-to-end innovation and reduce siloed operations and projects. 

    The companies that have embraced a product-centric operating model are quickly realizing the benefits, but for many IT departments, they have yet to experience or fully understand why the shift is imperative.

    What’s Driving the Shift to Product IT Operating Model?

    As digitization takes hold and becomes more and more pervasive, CIOs are realizing that intertwining IT and business objectives is quintessential to respond to market changes quickly and remain competitive. Since 2018, volatility has returned to global equity markets in a big way. With the economy in a constant state of flux, coupled with rapid globalization and unprecedented disruption from technology, the average lifespan of a company is 20 years, compared to 60 years in the 1950s, according to Credit Suisse. Overall, the changing business environment makes few things as abundantly clear as this–agility, an appetite for new markets, new products, bias for action and a fail-fast approach will be the new mandates for IT leaders going forward. 

    To this end, most CIOs are replacing portfolios of discrete, siloed projects with product lines that enable a specific business capability. The key factors driving the shift toward a product IT operating model include:

    • Need for Holistic Transformation: Siloed functions have no place in the digital business world that thrives on integration of data and information across structure, culture, processes and technologies. To enable holistic transformation, organizations must draw a balance and establish cross-collaboration between organizational guidelines versus autonomy of teams for process, architecture, technology, tools, etc.
    • Lack of Alignment in Traditional IT Operating Models: Lack of alignment across large teams and multiple organizational groups (such as IT, finance and business) prevents organizations from executing an end-to-end digital strategy. Shifting to a product IT operating model can help steer organizational units toward a common goal. It can facilitate greater collaboration between different DevOps teams that support different products and domains. Recognizing the failure of existing IT governance and the pressing need for a shared digital transformation vision, IDC predicts 40% of CIOs will adopt new digital governance models.
    • Need for Speed: Most companies cited that their digitization efforts were hindered by inflexible or slow processes with a traditional IT operating model. Adopting a product-oriented management approach for IT can help organizations define and agree on a pace of change congruent with their readiness and appetite. According to IDC, 65% of CIOs will expand Agile/DevOps practices into the wider business to achieve the velocity necessary for innovation, execution and change by 2021.
    • Lack of Integration Between Old and New Technologies: Lack of integration between new and existing technologies is a key factor that keeps organizations from realizing the full potential of digitization. Modern companies need to balance innovation, experimentation, adoption of new technologies and tools with the enterprise’s need for business results, cooperation, risk management and compliance. Because a product-centric model takes a holistic, end-to-end approach, it is ideal for integrating technologies, processes and teams at scale.

    Embracing a Next-Gen Operating Model

    To compete with newer, nimbler companies such as Facebook, Uber, Spotify and others, traditional companies that are serious about continued growth are leaving no stone unturned and embracing a product IT operating model. From being providers of reliable IT services, CIOs have emerged as strategic partners in driving business transformation. Modern day CIOs are driving business innovation and identifying opportunities for competitive differentiation, not delivering ad-hoc, siloed services. As cloud-first and AI-first become the new mandates for organizations, re-engineering the IT operating model is quickly becoming central to creating value, competitive advantage and growth.

    — Rohit Nand