devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Moving Things Around: The Acquisition of Protego

    Moving Things Around: The Acquisition of Protego

    I received a note from Protego Labs’ vice president of marketing about Check Point Software acquiring Protego. We see a fair number of acquisition announcements, and usually don’t write about them–though we read them and stay abreast of industry happenings.

    I used to follow Check Point, and haven’t looked into what they’re doing in a while, so I followed through links to both organizations and looked at their products.

    I found myself becoming the wizard that some call Tim. But instead of “What is your name? What is your quest? What is your favorite color?” I was looking into “Where is your site? What are your products? What value do you add?” My beard is kept trimmed, more along the lines of a knight’s, so it makes sense I would ask different questions. As long as I’m not spouting “It’s just a flesh wound,” I figure I’m doing okay.

    First off, this merger makes sense. Protego does it for serverless and Check Point is doing their best to be where your code is running. Indeed, Protego probably needed a merger of some kind because all they do is serverless. Check Point’s Cloud Guard Dome 9, by contrast, will protect access rights and data for serverless, but doesn’t do what Protego does–keep an eye on the code. So this is a good fit.

    But it once again brings to light an interesting issue as you move things from DC to cloud A to cloud B to serverless. Where are your support functions? Networking, security, storage…These things need to be where the code is, but architectural options are more than they’ve been for decades. And the architectures are largely incompatible. Consider network functions for a physical-server based DC versus a VM DC, versus a Container DC, versus Cloud…You get the idea. The array of functionality and where it runs is different. Different in implementation and different in maintenance.

    This was a problem I (and others) pointed out when cloud started taking off: more work for ops, even if some of it is automated. Turns out ops, storage management and security all have more work, because all of those items are handled differently in the different architectures. And Protego had to focus on one to get it right, meaning they needed some kind of merger in the long run.

    So do you. Adding more and more work to ops–be it DevOps or traditional ops–is not the answer. A plan for standardizing is necessary.

    That is one of the big promises of containers, in my opinion. Not only are they more agile and easier to use in a DevOps environment, they are relatively standardized. Ops will still have more work if you’ve got apps in several of those architectures, but containers obfuscate some of the differences and allow standardized networking within the pod/node/group, for example.

    Some functionality just doesn’t fit into containers–you still need a physical network in the DC, or to configure the virtual network in a VPC to get traffic to/from your containers–but much of it does fit. Once at the pod/group, networking is virtual and the same regardless of where the containers are running. Which reduces overhead while making changes easier. The same is true for security, and increasingly for storage.

    There are great companies out there tackling these issues, and I’ll look at them on occasion. Right now, I know my former employer F5 Networks is working to solve the networking services/performance/security issues, and taking advantage of NGINX to handle some parts the core org traditionally hasn’t addressed. There are other companies, I just hear about that one more because I am still very close to some F5ers.

    It is worth planning for and certainly worth looking into more portable options, anything that lightens the load and keeps your great apps running. Keep kicking rear and spinning up apps.

    And don’t call me Tim.

    — Don Macvittie

  • The Use of Feature Flags in Code: Too Many Flags?

    The Use of Feature Flags in Code: Too Many Flags?

    It is interesting to watch the growth of an idea over time. The idea of using flags in code to do different things is as old as programming itself. Old-school configuration files used them, and they worked, so they were adapted.

    Thing is, given an idea that works, humanity inevitably takes it too far, and flags to control software behavior seem to have reached that point. If you are using one set of flags for A/B testing, another to segregate code in development at runtime, another to turn functionality on for some users but not others and yet another set of flags to hide data based upon user…You’re buried in unnecessary code branches. If your organization isn’t great about cleaning up after flags are no longer needed, you are building spaghetti code that future developers will not thank you for.

    The best answer to this growing burden is focus. What is the best use of feature flags/toggles in your environment? They certainly speed the delivery process by having the code there, in nightly builds, just not executed until the flag is flipped. This helps in rollout also by allowing operators to turn a feature on when it is ready by changing config rather than redeploying the application.

    For A/B testing, in many cases it makes more sense to handle switching at a load balancer, where again it is a config, but separate instances serve the UI in question. This, like all decisions regarding flags, should be based upon the volume of change. Changing the contents of a list is likely easier to test with flags, but large volume of change is probably better run separately and switched off of a load balancer.

    The same is true with the volume of change in source. A rollout might be the best option for handling large volumes of change, and feature flags may simply create more complexity.

    As with everything, approach the problem with a plan that works best, in this instance, in your environment. There is no denying that the ability to turn on a new feature and then turn it off if something goes wrong is appealing, just use the idea judiciously. And clean up after yourself. No shop that uses flagging extensively will say “yeah, we don’t clean it up,” because the mess of nested checks for flags would slow the code and make it passingly difficult to even read, let alone maintain, over time. So approach it from the beginning with “It is a tool, and when it no longer serves its intended purpose (the feature is fully live or abandoned), we remove it.”

    And keep rocking it. You are the engine of business, and this is what you do. Make it great and keep it running.

    — Don Macvittie

  • The Benefits of Test-Driven Design

    The Benefits of Test-Driven Design

    At John Hancock, we use Test-Driven Design (TDD) for all our new initiatives. TDD has three simple steps:

    1. Before you write functional code, write a test that proves if the implementation works or fails.
    2. Write the code and watch the test pass.
    3. Check if the added functionality changes your holistic approach and if you want to consolidate/refactor some of your code. If yes, refactor these sections.

    That sounds simple enough, so why write an article about a three-step process? Why do we, at John Hancock Digital Enablement, get so excited about TDD? We have seen major impacts to our developers, products and culture:

    • Increased motivation and self confidence.
    • Shorter Release-Cycles.
    • Increased Code Quality.
    • Massive Reduction of Bugs in Production.

    The Foggy Path

    Imagine your development process like a foggy path, where you can see directly in front of you, but anything further away becomes foggy and imprecise. Imagine it like a journey into the unknown.

    Obstacles may appear suddenly, forcing you to rethink your approach (refactoring), or you may get above the fog after a long journey and realize that there is a much simpler way to reach your goals (also refactoring).

    This uncertainty and constant change may appear to be frightening and trigger anxiety, but TDD is the safety net, because you know that what you’ve built holds up against all the risks that have been identified. As a developer, I can take much higher risks and try different approaches and get quick validation.

    The test cases built out as part of the TDD flow are ideally integrated into a continuous integration/continuous development (CI/CD) Platform, giving fast and reliable feedback to the engineers about unexpected behaviors their code change may have caused. Because the feedback to the engineer is near instant, the developer is familiar with the change that caused the error and is able to resolve it rapidly. 

    TDD Is the Opposite of “Never Change a Running System”

    A well-known issue is that the later a bug is found, the more costly it is to resolve. TDD enables fast feedback loops so bugs can be resolved quickly and cost efficiently.

    As an application grows, TDD gives you a solid foundation of everything that has already been built. You can be confident that what you have built is solid and that new functionality can be added to it easily and without taking the risk of breaking everything. In other words, TDD is the opposite of “never change a running system” and enables us to build even better software. 

    TDD Always Provides Up-to-Date Code Documentation

    TDD provides excellent documentation toward the requirements and behaviors of the application. While documentation always lags behind the functional code and typically is written after a functionality is implemented, in the world of TDD everything starts with a test. The test documentation is always up to date and gives developers an easy and understandable way to figure out what the application is achieving without dissecting the entire code.

    The following quote from Terry Pratchett explains it best: “If you do not know where you come from, then you don’t know where you are, and if you don’t know where you are, then you don’t know where you’re going. And if you don’t know where you’re going, you’re probably going wrong.”

    As an application grows, evolves and is built up over time, and as it’s passed down and handed over, TDD gives it documentation and describes its solid foundation. The act of writing a test case forces a developer to stop and think about the functionality that is to be implemented and describe its desired outcomes.

    TDD Provides Early Feedback 

    Through TDD we receive early feedback about the path we are about to set foot on. Early indicators can help us correct our assumptions or help rephrase or rewrite a requirement so that we deliver customer value. 

    Early indicators that we’ve encountered: 

    • Functionality cannot be measured: Why are we implementing this if we cannot measure its outcome?
    • Functionality does not add any value.
    • Functionality cannot be tested: Similar to the first bullet, if a functionality cannot be tested, how can we accept it’s delivery? 
    • Functionality can be easily embedded into an existing part of the application that needs refactoring: This can trigger the refactoring before we start the implementation.

    As described, it is very helpful to think about the steps ahead before jumping in, which can be difficult for engineers to do. TDD does so in a language that is natural to engineers.

    TDD Embraces an Ever-Changing World and Removes Fear of Change

    TDD as a part of eXtreme Programming (XP) accepts and embraces an ever-changing world we cannot control. Changes may cause discomfort and anxiety as planning becomes difficult/different.

    In an unstable, disorganized software project, changes are thrown at it, a solid foundation is missing, testing is skipped or postponed to the end and refactoring is skipped all in the name of on-time delivery. The first delivery of the application may be on time, but as time goes on the anxiety grows, there are random bugs everywhere, the more bugs that are fixed, the more issues pop up and you essentially end up playing a game of whack-a-mole in which you will never be in control.

    In a project that embraces XP principles, such as TDD, we try to remain in control from the beginning, facing challenges early so they do not bite us later on. A solid test base gives developers, and everybody else on the team, confidence that the delivered solution will work, but most importantly it removes the fear of change.

    Without fear of change, we can try all sorts of crazy things, test out ideas and see them turn out or fail without the code failing, without losing a customer, without getting that phone call in the call center. 

    Traditional QA and Release Cycles Are too Slow for this New Era of Ever-Changing Needs

    As software grows, its testing becomes more intense. So, with each new piece of functionality there must be a corresponding test case. The manual execution of those tests becomes lengthy, the feedback loop to the developers slower, releases get held up, customers do not get new functionality in time and, in the end, money is lost.

    Traditional QA and release cycles are too slow for this new era of ever-changing needs. What if I want to release daily or weekly? Do we have to execute the test procedures every time? What if bugs are found and repaired? Do we need to rerun the entire set? 

    The answer is yes—but if a machine does it in a few minutes, who cares? 

    While I am not a proponent of no human testing, what I am saying is that 95% of manual QA can be automated and executed by a machine, and TDD provides a fantastic test set to get started with. Humans may catch errors that are hard for a machine to identify or imagine since human behavior is hard to predict, so spot testing as well as exploratory and behavioral testing are still needed.

    We Are Left with a Team that Is Hungry for More and Only Afraid of the Enormity of the Possible

    What are we left with at the end of a TDD project? We have a well-documented, easy to understand, easy to change and stable code base lead by a team that is not afraid of change. We are left with a team that is hungry for more and only afraid of the enormity of the possible.

    — Niklas Studer

  • 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

  • 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

  • There’s No Such Thing as an Open Source Business Model

    There’s No Such Thing as an Open Source Business Model

    Open source technology works best when it’s adopted as a series of strategies and tactics that support a core business model—not the other way around.

    With all the talk about open source business models, the title of this article might seem a bit odd—especially when is written by someone whose entire job is to support an ecosystem surrounding an open source software project. Bear with me.

    We all know what comprises a business model. But when we focus a company’s products around open source technologies, we suddenly start acting like there’s something fundamentally different about the business itself. 

    While I agree that open source, as both concept and movement, has made a huge impact on our economy across nearly every industry, it’s my belief that many enterprise technology companies (especially startups) are losing sight of the difference between their business and the open source projects to which they are tied.

    Pressures on an Open Source Oriented Company

    Venture capital-backed startups in search of an open source business model quickly find themselves in a tough situation. Investors want returns, but the open source community expects free software and a healthy community. Other pressures, such as the natural erosion of differentiating features in a commercial version of the software through the community’s own development efforts, add to the stress. 

    Furthermore, the more the open source version of the software is used in the enterprise, the more likely that competition will emerge. The most challenging competition for software vendors is that hyperscale cloud providers can offer fully managed versions of the open source software. These cloud providers pride themselves on being quick to recognize the opportunity to support customer adoption of open source. This is intimidating to founders and investors alike, but attempting to create new “almost” open source licenses isn’t the answer.

    When It’s Done Right

    Instead of thinking of open source as a core component of your business model, define a business model that can stand on its own as a software or services company. Open source works best for a technology company when it’s adopted as a series of strategies and tactics that support an otherwise sound business model—not the other way around.

    I’m not the only person in this space that thinks this way. Earlier this year at the Linux Foundation’s Open Source Leadership Summit, I had the pleasure of seeing GitLab CEO Sid Sijbrandij share details about how the company he co-founded iterated and eventually landed on a business model that takes advantage of open source technology without being completely reliant on it.

    Open source is a shared approach to research and development among a community of individuals or like-minded companies working together to create an asset for anyone’s use. The entire notion of open source is predicated on the creation of a community for the purpose of developing software that can help organizations of many types and interests achieve their desired outcomes. This community—which includes your customers, end users of the open source software and even competitors—is where open source projects are able to create massive amounts of value. The trick for any company building, or helping to build, open source projects that are key to their commercial efforts is to focus on dual tracks:

    1. Support the growth of the community.
    2. Ensure you monetize a reasonable percent of the overall value that is being created.

    GitLab has been very thoughtful about its approach. While the core of GitLab’s product is open sourced, the DevOps lifecycle tool was built with multiple components that create a more valuable experience than any open source technology can deliver on its own.

    The critical challenge for GitLab—and any business, frankly—is revenue generation. Instead of selling itself as an open source vendor, GitLab has wrapped multiple proprietary features around its open core. That, in turn, allows GitLab to package proprietary features and support for that open source core as a more impactful and valuable proposition for enterprises.

    The goal is to create something that is unique and unlikely to be replicated or commoditized by other vendors. GitLab focuses on selling predominantly to executives and, to a lesser extent, it sells a lower cost version of its product to departmental managers. It also offers a free version to individual developers or small developer teams to drive adoption, interest and shared development of its open source core.

    GitLab made the bold decision to make a full-featured version of its Git-repository manager available for free to small teams. As with any software, once it’s adopted more broadly within an organization, new challenges will arise. That’s where a company can come in and offer enterprise-scale licenses, complete with features that solve problems that are unique to that wide adoption.

    That’s a very big difference in the way GitLab thinks about its business model, and it has led to a series of clear decision points about what it should make proprietary and what should be included in open source software. This approach allows them to build a community around open source, affords them ample goodwill, a groundswell of adoption and the benefit of tremendous developer feedback. It’s a perfect example of a company that uses open source for a set of strategic goals that supports a standalone business model. 

    Your Next Move

    It’s critical for some aspect of your business to be proprietary or well-differentiated from open source projects that are readily available. Adding capabilities, integrations, different features and enterprise class support will extend what an open source project can accomplish on its own.

    For example, if your product requires enterprises to put in a lot of work to adopt and implement it, it makes perfect sense to develop a strong services division as part of the hook to make your organization critical to the success of its customers. We should all be striving to solve difficult problems that are fairly unique to larger enterprises. 

    Remember: there’s no such thing as an open source business model. The business needs to make sense on its own. Work from the outside in, rather than the inside out.

    — Chip Childers

  • 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

  • Survey Sees Massive Adoption of Microservices

    Survey Sees Massive Adoption of Microservices

    Under increasing pressure to innovate faster, a majority (84%) of organizations taking part in a recent survey have already embraced microservices.

    The survey, conducted by Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT leaders in organizations with more than 1,000 employees. Among the results, 89% of technology leaders agree that companies that are not able to effectively support microservices will be less able to compete in the future.

    The report also finds on average organizations are running 184 microservices, with 60% of respondents running 50 or more. The primary reasons cited for adopting microservices are improvements to security (56%), increased development speed (55%), increased speed of integrating new technologies (53%), improved infrastructure flexibility (53%) and improved collaboration across teams (46%).

    Kong CTO Marco Palladino said the report makes it clear that just about every organization is on a journey to making a transition to microservices as part of an effort to reduce reliance on inflexible monolithic applications. Initially, that transition involves lifting and shifting monolithic applications in the cloud before decoupling functions using microservices, he said.

    As part of that journey, Palladino noted, the survey also finds significant microservices challenges remain, including ensuring security (36%), integration with legacy applications (32%), the complexity of management (31%) and updating API documentation (31%).

    Despite these concerns, however, more than 80% of survey respondents who have adopted microservices report that their organization performs well against metrics for development efficiency, the ability to use new platforms, collaboration across teams and sharing of services across applications.

    Overall, a full 90% of respondents said securely connecting applications and ensuring performance at scale collectively represent one of the greatest technical challenges of the 21st century. Also, 71% said they believe that organizations would be out of business within six years if they fail to keep pace with innovation in their industry. For public companies, the urgency is even greater, with 39% reporting they believe organizations will be out of business in less than three years if they fail to keep pace with innovation. Overall, 57% of technology leaders feel organizations are concerned that they are at risk of competitive displacement.

    Pressure on IT leaders is high as a result. Nearly three-quarters of respondents (74%) agree that a failed digital transformation effort will result in a missed promotion, lost bonus or even termination. The report identifies the top three priorities for IT leaders as improving efficiency (47%), reducing cost (41%) and increasing security (40%).

    Technology leaders, however, continue to place the highest importance on the availability (75%), security (74%), performance (65%) and scalability (64%). At the same time, technology leaders are focused on faster development speeds (95%), increased collaboration (94%) and reduced deployment risks (93%) as key desired outcomes for adopting any new technologies.

    The challenges most cited in terms of achieving those agility goals are the complexity of using multiple technologies (35%), lack of automation (32%) and reliance on legacy technologies (29%).

    The survey also notes 83% of organizations are relying on open source software to become more agile. The most commonly used open source technologies are databases (64%), containers (48%), API gateways (41%), infrastructure automation (40%), container orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%).

    In terms of cloud adoption, Microsoft Azure (43%) narrowly beat Amazon Web Services (AWS) (42%), with Google Cloud Platform (GCP) coming in third at 27%.

    On the plus side, 78% of respondents said their organizations are increasing IT budgets in the coming year, with 27% of public companies expecting their budgets to grow 26% or more. Nearly 90% of companies will also be increasing headcount, with 56% hiring internally and 31% relying on more freelancers and/or outsourcing to meet hiring goals.

    Hopefully, with that increased funding more organizations will be able to strike that elusive balance between stability and innovation.

    — Mike Vizard

  • 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