devopsy.kinsta.cloud

Tag: devops

  • Don’t Leave Software Testers Out of DevOps

    Don’t Leave Software Testers Out of DevOps

    The term DevOps implies that software delivery is all about integrating the development and IT operations teams. But the software testing team is an important, if oft-overlooked, part of the picture. Here’s why.

    Could you deliver software continuously without involving the QA team in the continuous delivery pipeline? You could try, but it would probably not go well. Software testers play a vital role in continuous delivery, for the following reasons:

    They are the glue connecting developers to IT Ops. If there is no one to test the code that developers write, IT Ops cannot deliver a stable product.

    They help find problems before they become costly. If you skimp on integration, unit and performance tests, you won’t find problems in your software until after it reaches users. By that point, fixing those problems will be much more time-intensive than it would if they had been caught early on. Plus, your organization’s reputation will have taken a hit, because problems that could have been nipped in the bud prior to delivery ended up affecting users.

    They know things that developers and IT Ops don’t. If DevOps is all about continuous visibility across the delivery chain, then it only works well when the delivery team’s collective expertise covers all parts of the delivery process. Since developers and IT Ops people are not experts in quality assurance or testing, you need to involve testing professionals in the continuous delivery chain so that they can help everyone else understand the parts of the process that QA professionals know in detail.

    All of the above is to say that if the QA team is not plugged into every stage of the delivery process, your software either won’t be tested efficiently, or it won’t be tested at all. Not testing efficiently means that the QA team is not in sync with the rest of the organization. In this case, the QA team would delay software delivery because it would have to wait on developers and admins to complete its work, and vice versa.

    Not testing at all, of course, is even worse. No one should deliver unvetted software to users.

    Don’t Forget about QA

    The takeaway for organizations seeking to adopt DevOps practices is this: Even though the DevOps conversation on the surface may seem to be about only developers and IT Ops professionals, QA teams play an equally crucial role in continuous delivery. They need to be as involved in the continuous delivery pipeline as everyone else if an organization wishes to reap the full benefits of DevOps.

    — Chris Tozzi

  • Every Business Has Become a Technology Business

    Every Business Has Become a Technology Business

    Contributor: ITSM ACADEMY-Drew Lapatin

     

    Every business has become a technology business.

    Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog), and when should we retire them (retire).  We literally could be an app away from becoming irrelevant.

    It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often.

    By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer requirements more effectively. Normally projects will start with a given set of requirements.  In an Agile project (yes, we are going to use an Agile project format to continue the theme of blending ITIL and DevOps) the product backlog will contain these requirements as user stories, but as we all know those stories/requirements/attributes can change very rapidly. One tool that could help us rank these attributes and ensuring the delight of customers is the Kano model.

    A Kano model shows us there are three different factors in customer satisfaction.

    They are as follows:

    • Basic factors are aspects of the service that have to be in place for the customer to receive the service. They may not offer any obvious value, but if they fail, or are not delivered, customers will become very dissatisfied. These factors are sometimes called ‘must-have utility’ or the very least the service provider can deliver for a particular service.  Basic factors are not responsible for high levels of satisfaction, unless they alone fulfil the customer’s requirements completely.
    • Performance factors are factors that enable a customer to get more of something that they need, or a higher level of service quality. These are the factors that customers are interested in and the price they are willing to pay is directly impacted.  These factors result in customer satisfaction when delivered and customer dissatisfaction when unfulfilled.
    • Excitement factors are attributes of a service that are generous, and which customers do not expect. When they are offered (within reason) they cause higher levels of satisfaction. The service provider is seen to be ‘going the extra mile’. While excitement factors result in the quickest and highest levels of customer satisfaction, they are expensive to maintain, since the service provider is offering more than necessary at the same price. These factors may be exciting, but they are not essential to the service, and are therefore also referred to as ‘nice-to-have utility’. Internal service providers should be careful of introducing excitement factors in the interest of ‘customer satisfaction’ without doing a proper business case to justify the additional costs.

     

    Drew Bio

    — Alice Acedia

  • Making Performance More Than a Best Practice

    Making Performance More Than a Best Practice

    Yes, you read that correctly: SRE means that strong application performance—speed, reliability and availability—no longer is simply a best practice. It is a must. Site reliability engineering, or SRE, is a term Google coined several years ago, and while there is no universal definition, SRE can be thought of as a discipline that blends software engineering with IT operations management. At the heart of the SRE model is a site reliability engineer who knows how to code as well as handle ops. The SRE concept is similar to DevOps, which is intended to bridge the divide between development and operations teams, but until now has not caught on the same way DevOps has.

    The Need for SRE

    The rise of the digital economy is now propelling end-user application performance to the top of the IT priority list. According to a recent EMA Survey, 55 percent of IT professionals rank end-user experience monitoring as their top application management priority. At the same time, growing IT complexity, including the cloud and multi-platform applications, are making it more difficult than ever to ensure strong user performance and identify the root source of problems before they escalate. We believe this performance imperative is driving the SRE resurgence, giving DevOps teams the necessary “teeth” to govern and resolve performance-related disconnects, swiftly and decisively.

    Performance issues traditionally have been a lightning rod of conflict for even the most well-oiled DevOps teams. Developers, relentlessly focused on rolling out new products and features, keep throwing their “completed” work over the fence to operations. Operations teams, conversely, are focused on minimizing change and maintaining stability as much as possible. These opposing desires naturally create friction.

    Performance problems only exacerbate this. Developers, who have already moved on to the next must-have feature, say it’s operations’ fault. Operations points their fingers at the developers, saying that poorly written code is to blame. No one is assuming responsibility and the developers and operations teams are stuck in a stalemate. Meanwhile, users are suffering, the call center is being inundated, revenues likely are circling the proverbial drain and the situation is quickly reaching a boiling point.

    SRE is valuable because it finally brings an end to this suffering through a set of clear, irrefutable, mathematically based rules to govern all DevOps efforts and decisions. If a new piece of software achieves a targeted performance level, further rollouts can proceed. If not, future releases will halt until the first piece of software is fixed. The site reliability engineer, who is well-versed in both development and operations, serves as an independent arbiter who provides a clear assessment of where the root cause lies—on the development or operations side of the house. With guidelines firmly established and a central, unbiased person in charge of determining the right course of action, the developer/operations friction can be avoided and problem resolution can commence.

    In an SRE model, developers and IT operations also share a staffing pool. If there’s budget for one hire, and a product is not delivering an agreed-upon performance level, the hire goes to the IT operations. If the product is delivering the required performance level, the hire can go to development, which will help the development team roll out new features and products.

    The real beauty of SRE is that both sides have a vested interest in achieving strong application performance, ideally right out of the gate. If whichever side owns the problem does not fix it, they can forfeit any hopes of adding manpower to their team, at least in the near-term. There’s another more serious implication: for developers, there will be no further development; and for operations teams, less software to support may translate to lower headcount requirements.

    An SRE approach has many advantages, including fostering a vested interest in performance across the entire DevOps team, and holding feet to the fire. Performance cannot be an afterthought—performance must be considered and measured from the very beginning phases of ideation and development all the way through production and post-production modifications. Users don’t care how fast or efficient your DevOps team was if the ultimate work product does not perform—in fact, this means the whole effort likely was in vain. Like a strict adjudicator, SRE may just be what DevOps teams need to bring to an end to performance-related squabbles once and for all.

    About the Author / Mehdi Daoudi

    mehdidaoudiMehdi Daoudi is CEO and co-founder of Catchpoint Systems, provider of web performance testing and monitoring solutions. Before Catchpoint Systems, he spent 10+ years at DoubleClick and Google, where he was responsible for Quality of Services, buying, building, deploying, and using monitoring solutions to keep an eye on an infrastructure that delivered billions of transactions daily. Connect with him on LinkedIn and Twitter.

  • Don’t Be Samsung: Here’s How You Can Protect Yourself

    Don’t Be Samsung: Here’s How You Can Protect Yourself

    Imagine a factory building 100,000 units a day, and you can see how a small error can have huge consequences. Now imagine that factory is a database.

    The world’s top smartphone maker this month pulled the plug on its $882 Galaxy Note 7 after phones overheated and caught fire, concluding in a disastrous recall for Samsung that could cost the company as much as $17 billion and shutter a global revenue stream. In an unprecedented move, Samsung has told mobile carriers to halt sales or exchanges of the device, requested that users to shut off their phones and issued a mass recall while the South Korean manufacturer investigates reports of fires in original and replacement Note 7s.

    This a scant two months after the Galaxy Note 7’s launch, a device that one TechCrunch consumer electronics expert raved as “undoubtedly one of the most iconic handsets around.” While it is not clear what caused these fires, there is speculation that it was due to a faulty component that interacts with the battery, rather than the battery itself.

    It goes without saying that there are ample opportunities for error in the assembly of a smartphone. The complicated, highly coordinated process is fraught with thousands of input touchpoints, from hard- and software components to tightly controlled manufacturing processes to manual labor. And though there may be countless checks and balances in place, mistakes do happen. What may seem to be an innocuous error, such as not sufficiently tightening a screw or the shorting of a circuit, in this case has led to epic consequences.

    The truth is, these instances happen more often than we think, and to technologies even more vital to the population than a personal smartphone.

    Consider today’s era of big data and cloud applications, where enterprise applications ingest and process vast amounts of information from various sources, often in real time, to deliver critical analytics, contextual information or business insights.

    This data has weight. It can influence whether fleets of airplanes are grounded at gates all across the country. It can restrict customers from accessing funds from online banking. It can dictate whether millions of online retail dollars go unspent. The reliance on accurate data, and its grip on lives and business, is growing at an exponential rate—like ever-widening ripples in a lake.

    To support all of this data, new applications (such as real-time analytics, internet of things, ecommerce and others) are developed and deployed on scale-out, non-relational databases or ported from traditional relational databases.

    But, like the manufacturing gaffs experienced by Samsung, corruptions and operational errors by developers occur in enterprise IT environments. Enterprises know this, and billions have been invested in traditional backup and recovery and data protection products to protect against such “err” moments. However, the irony is that data protection products like those that exist for traditional relational databases do not exist for today’s modern, next-generation scale-out databases supplying the new types of data that increasingly control our lives. We’re essentially trusting that the Ma Bell rotary phone repairman will be able to recover personal data—such as contacts, photos and messages—after your Galaxy Note 7 starts smoldering.

    So how did we get from the world’s most explosive phablet to distributed databases and big data? Because, like the Galaxy Note 7, the tiniest data error can rapidly expand into magnificent, catastrophic consequences.

    Enterprises are adopting cloud applications that gather large amounts of data at a high-ingestion rate and process that data in real-time to deliver actionable insights. These applications are deployed on non-relational databases. As migration to cloud and multi-cloud application environments increases, enterprises also must be able to manage and recover at scale without data loss or corruption and with minimal application downtime.

    However, enterprises today face a significant gap in addressing their data protection requirements. Their most valuable data, often needed 24/7 and without fail, runs absent any point-in-time backup options for that ‘“Houston, we have a problem”’ moment. Most studies suggest that more than half of data downtime and loss is triggered by human error, corruption or virus attacks. And yes, while native replication helps enterprises meet business continuity and disaster recovery requirements by providing protection from hardware failures or even natural disasters, it is insufficient (meaning it cannot scale) to meet next-gen enterprise data protection demands. Case in point: If a minor schema corruption impacts the primary data copy, it causes a multitudinous ripple effect that impacts all replicas down the line. Yet, even without protection, industries continue to adopt and deploy scale-out database systems at an accelerated pace.

    So just as Samsung witnessed an error replicate itself into such a massive meltdown of global proportions that it threatens to kill an entire product line, organizations also must understand how replication-based protection mechanism can actually act like a virus—spreading a corruption uncontrollably across non-relational, cloud databases.

    Samsung’s troubles won’t end with the simple recall of a single product, and their predicament should resonate. There will be punitive measures, and perhaps even a total enterprise shift from the smartphone market. It is not an enviable position, but is does offer a clear example of how a peripheral manufacturing error can swell to engulf an entire brand.

    For enterprises rushing to deploy scale-out databases, let Samsung serve as a warning: that deploying any infrastructure that could potentially lead to exponential, irreversible corruption of all data copies is a recipe for harm (if not disaster). As enterprises make the switch to next-gen applications running on scale-out, non-relational databases, an assembly line e-stop needs to be built in, in the form of a point-in-time, version-friendly data protection solution.

    Data corruption is not a matter of “if,” but “when.” So have a kill switch ready.

    errors-replicating-image

    — Brian Yin

  • What the Current DDoS Landscape Means for DevOps

    What the Current DDoS Landscape Means for DevOps

    Businesses, governments, hospitals, schools, charities and even individuals—they’re all the same to a DDoS perpetrator. If you have a website, it’s likely to be targeted by a distributed denial of service (DDoS) attack at some point.

    DDoS has the potential to shut down your site for days and create havoc with an organization. They can be expensive and—most worrisome—can taint your reputation and discourage users and customers from ever returning if your site is unavailable on any given occasion.

    Perpetrators have been known to exploit network packets and all types of vulnerabilities, including writing custom code dedicated to knock down a specific application or service, to overburden systems or stop them outright.

    Attack Motivation

    There are plenty of threat actors ready to launch a DDoS barrage. Some of them include:

    • Hacktivists using DDoS to express their discontent with businesses, governments and individuals.
    • Cybercriminals relying on pre-made scripts and tools to take sites down. Some instigators are simply looking for a way to vent their anger or frustration. Some may use commonly available DDoS-for-hire websites instead of running the attacks from their own network.
    • Extortionists who blackmail sites, demanding money in exchange for stopping (or not carrying out) a DDoS threat.
    • Business competitors seeking ways to exclude rivals from significant events (e.g., Cyber Monday), or attempting to completely shut them down.
    • State-funded threat actors engaging in cyber warfare to silence critics and opponents. They also can target civic infrastructures to cripple opposing countries.
    • Attackers who attack just because they can, or for no obvious reason, other than test their ability to carry out an attack.

    DDoS Types and Trends

    But DDoS events don’t just disrupt service. According to “Cloud Security Alliance Guide to Cloud Computing,” hackers are also using them to steal information and infect computers for a variety of nefarious purposes.

    In addition, DDoS assaults are growing rapidly in both number and volume. International Business Times states they’ve become more commonplace because readily available tools and cheap online services let anyone aim an attack against a company or individual server.

    DDoS attacks can be divided into three types, with numerous (and unique) variations within each.

    Volume-based attacks saturate the bandwidth of a site. Imperva Incapsula, a cloud-based security and acceleration provider, faced the largest such attack on its record in 2Q 2016, peaking at 470 Gbps. Like many other complex, high-rate assaults, attackers used small payloads to achieve a high packet forwarding rate—a dangerous new tactic that has become common.

    The main purpose of such attacks is to take down mitigation services by sending out a rapid burst of packets at a rate many anti-DDoS appliances can’t handle.

    Protocol attacks (aimed at the OSI layer 4) consume server resources such as firewalls and load balancers. Network layer attacks have grown in size, number and sophistication. Those using multiple vectors have climbed to a record-high 36.1 percent, reports Incapsula. On average, it mitigated a 50+ Mpps attack every three days in that quarter.

    Network layer attack duration increased in the same period, with 13 percent lasting for over an hour. The longest persisted for more than 10 days in a row. While most are in the hit and run category—using short bursts launched against the same target—an uptrend points to the prevalence of events lasting more than six hours.

    Application layer assaults (targeting layer 7) are comprised of seemingly legitimate HTTP requests, attributed to bad bots that have also grown in sophistication. An ongoing salvo of requests originating from numerous masked IP addresses can bring your web application down in no time, by creating stress on the web servers, database servers or other elements of the web application.

    The largest such event mitigated by Incapsula in 2Q peaked at 108,288 RPS (requests per second). The longest ran its course over 67 days, while 59 percent lasted less than 30 minutes. The company attributes this to an increased number of “casual” offenders.

    Examining Risk

    The Open Web Application Security Project (OWASP) offers a brief look at risk assessment:

    • “… inadequate resources, requires attention if system architecture was not designed to meet traffic demand overflows … left unchecked, [it can] result in DoS symptoms absent an actual attack.
    • “… perhaps the largest risk factor is not technical … An organization should avoid taking action that can make them a target of a DoS attack unless the benefits of doing so outweigh the potential costs or mitigating controls are in place.
    • “Other risk factors may also exist depending on [your] specific environment.”

    The first item above can apply to any website. While one might think that the second might only be applicable to political entities, what about ecommerce sites based on competitive pricing? Unless strong DDoS defenses are in place, such a site won’t last long in today’s ultra-competitive digital world.

    So what can an organization do about fending off DDoS attacks? With assaults becoming both easy to launch and more sophisticated with each passing day, it’s imperative to keep up to date regarding the evolving threat landscape.

    Securing Your Apps

    Using software and plug-ins for which the latest security patches have been applied is a great start. Penetration testing is a highly recommended critical step before going live. Here, OWASP offers a complete online guide to assist you in your efforts.

    OWASP also offers several examples showing where code vulnerabilities may have been overlooked, ranging from user-specified object allocation to locking customer accounts.

    Once your app has gone live, monitoring site traffic to benchmark volume and visitor types helps ensure its reliability, as unwanted traffic can be detected and quickly addressed. Assessing traffic flow summaries is a start, followed by such tasks as examining IP source geography and unique source IPs hitting your site.

    But data analysis is only a start. SANS Institute offers this guide to help you learn more about successfully mitigating a DDoS attack.

    Most importantly, your operations team can create a response plan to minimize the impact of an assault. An effective plan includes procedures for your customer support and communications teams, as well as keeping CxO executives in the loop.

    Choosing the Right Mitigation Option

    Find a mitigation strategy that works best for your specific business needs. Planning includes prioritizing your concerns and examining the benefits of various mitigation options against your security budget. This is where it’s potentially more cost-effective to engage specialty security services (and their dedicated teams) rather than to try to “roll your own.”

    Ensure the DDoS protection you currently have offers the scalability and security capabilities needed to keep your site and server from crashing in the event of an attack.

    About the Author  / Ben Herzberg

    ben-herzbergBen Herzberg is security research group manager for the Imperva Incapsula product line at Imperva. Ben’s a  developer, hacker and technical manager, deeply interested in different technologies and focused on information security. He enjoys developing something new that just wasn’t there before, or solving a puzzle in a different way. Connect with him on LinkedIn and Twitter.

  • Why PR, Legal and HR Matter for Continuous Delivery

    Why PR, Legal and HR Matter for Continuous Delivery

    By most definitions, DevOps involves making developers and IT Ops teams work better together. But integrating other parts of an organization, such as legal and public relations, into DevOps is also important. Here’s why.

    DevOps has become popular because it helps to speed the delivery of software. The goal is to reach continuous delivery, which means code is changed, tested, staged and delivered to users on a (nearly) continuous basis.

    If you think only from a technical perspective, then getting to continuous delivery of software involves only technical people. Developers, IT Ops admins and software testers are all you need.

    DevOps in the Big Picture

    Yet, to deliver software continuously on a reliable basis, you need to think beyond just technical processes and personnel. Effective DevOps workflows have to involve all of the other parts of the organization that play a role in creating software, delivering it to users and maintaining it once it is in production.

    For example, PR teams need to be plugged into the software delivery chain so they know when new features are coming down the pipeline and can prepare to promote them. Legal professionals should play a role as well, since they’ll know when code changes require tweaks to licensing, compliance procedures and so on.

    The list can go on. In most organizations, human resources has a role to play in DevOps, since personnel changes can affect the continuous delivery chain. Supply chain managers should be involved, too, since they have a hand in provisioning the infrastructure on which DevOps teams rely.

    To be sure, these various non-technical teams don’t need to be as plugged into the DevOps workflow as deeply developers and admins do. Code can be written and tested without their perpetual involvement. Still, at a minimum, all parts of the organization should at least be aware of the state of the delivery chain. Otherwise, visibility and communication break down.

    Taking this big-picture approach to DevOps is important because ultimately, despite the relatively narrow purview implied by the term DevOps itself, the value of DevOps lies in adding efficiency and promoting better communication across the entire organization in ways that optimize software delivery.

    So, if you want to make the most of DevOps, start thinking beyond just Dev and Ops.

    — Chris Tozzi

  • ‘Best’ is Relative, but Starts at the Top

    ‘Best’ is Relative, but Starts at the Top

    Your aging mom needs a new car. You are picking it out for her because she quit paying attention to cars long ago. All you ever buy is Fords. You also always buy trucks. Do you pop off and buy your Mom an F350? Not unless she actually needs an F350 (highly unlikely, but aging moms are as varied as any other group of people, so maybe). Why? Simply because you are buying a vehicle to solve a problem: Your mother’s need for a new car.

    Ford F350
    Ford F350

    Setting the parameters of decision-making is the CIO’s role. Or at least a part of it. IT has struggled with justification since its inception. Far too often we are justifying choices that are made before justification is carried out. Browser wars, OS wars, language fights … all have marred IT practically from the day that an IT staff became necessary.

    The fact of the matter is that people have preferences, and organizations do, too. If you have 300 instances of Oracle database running, you have investment in staff, training, licenses, etc. that you can reuse if Oracle is a choice on the next project. Contrast this with “the next project” containing a purchased package that only works with SQL Server. The two are natural tensions that need to be figured out.

    In far too many cases we zero in on what an individual thinks is best or “right,” and not on the needs of the organization across projects. On the development side, Agile has made this more of an issue than it has been in a long time, maybe ever. Simply put, the faster the better is the rule for Agile, but long-term ramifications of that approach can be large. If internally developed apps vary from NoSQL to SQL server to Hadoop to Oracle and you’re having to maintain all of the above, both in Ops and in Dev, you may have delivered quickly, but the accrued cost—call it the mortgaged technical debt—can be expensive over the long term.

    And the way that we end up with multiple solutions to a given problem is by allowing champions to drive their point home in a vacuum. While it is great when an employee says, “I know a [needed library, tool, app] that will solve this and I can have it running in a day,” there is a larger picture that needs to be considered.

    DevOps definitely gives us the opportunity to review these choices and put a stake in the ground. Sometimes the internal champion is right, and that’s the tool to use in this scenario. Sometimes they’re not, and an already implemented tool/library/app should be used. But the conversation needs to happen.

    I wrote about some of this back when I worked for F5. It was amazing to me the number of customers who purchased F5’s very expensive gear, then set it up as a load balancer and went looking elsewhere for WAN optimization or security solutions, when the BIG-IP could do the job. That’s a good example of waste, but just the tip of the iceberg.

    When implementing DevOps on the Ops side, take a look at what you have. If you’re writing the same script for three different targets, it is probably time to go find out why. The reasons might be perfectly acceptable, but they might not be. If purchased apps really only support one product for AAA, then that product is probably required, even if it means propagating logins across to the corporate standard AAA tool.

    But the process to make certain these decisions are being made intelligently, with a focus on standardization but adaptability to handle exception cases, is driven from the top. Stressing that first choice is X, but Y and Z are acceptable alternatives for projects of priority three and above is important. Stressed from the top it says, “We have standards, and we all need to try to adhere to them to keep workloads down as much as possible, but we have a business to support, and will make exceptions where business value is added.”

    It’s not always easy. Not politically, and not technologically. Sometimes the solution available internally isn’t a perfect fit for a given problem, but long-term, the work required to make it solve the problem is less than the expense (in duplicated expertise and licensing fees, let alone duplicated DevOps scripts) to drop an easier solution in. IT staff are smart folks and fully capable of making those decisions, but the direction to do so must come from the top. Without it, some will aim for standardization over speed of implementation, some the opposite. Inevitably, many will aim for what is easiest for them.

    I have worked in two industries where data went from paper in filing cabinets to microfiche to mainframes to client/server to virtualization and/or cloud. Don’t assume what you’re doing only matters for now. Make the rules, ask the tough questions such as, “What do we have in-house that could fulfill this function?” and expect honest answers.

    And if you’re going to do calculations such as TCO or ROI, make sure the team knows you want the numbers to lead to the solution, not the other way around. Because we all have seen the case where the solution changed how the numbers were calculated, and that just wastes everyone’s time.

    So step up, Mr. CIO. Get Mom the Focus or a Honda—whatever will suit her needs. Not what you’ve always done, and not what is easiest for you to do. Set the rules so the team knows what decision criteria are, and make them clear so there is no miscommunication. And finally, give your DevOps team the room to make consolidation recommendations. If they’re seeing duplication of effort, let them call attention to it, and have a process to resolve their concerns. In the end, a simple, “No, that duplication is necessary because of X,” or “Yes, we should consolidate,” needs to come out of that process for each recommendation they make.

    And if your Mom is that one that drives an F350, send me a picture of her by the truck. I’ll talk to the editors about getting it posted.

    — Don Macvittie

  • To DevOps Or Not To DevOps

    To DevOps Or Not To DevOps

    Although enterprises today all claim to be software companies, there remain four distinct groups of organizations: the technology leaders, the technology followers, the technology hopefuls and the technology laggards.

    The first group are the industry leaders who are paving the way. These are the organizations coming up with new technologies, processes and cultural shifts. They write articles and books and present at conferences, and despite perhaps working at smaller companies, they are the names you may recognize. These are the companies the rest of us aspire to be—the Googles, the Amazons and the Microsofts that keep the rest of the industry hanging on to every word.

    The technology followers typically are smaller organizations that tend to adopt the latest and the greatest technologies. They are the leaders’ first wave of followers who are not afraid to try new things, nor afraid to fail. They have cultures that allow them to experiment and adapt and are given a lot of free time to invest in learning and implementation, after they watch the big guys successfully implement.

    However, the first two groups are the minority of software organizations, since not everyone can lead the way, nor can everyone have the luxury of spending a significant portion of their time experimenting with new methods. After all, most of the new technologies do not have a long lifespan. They appear, generate some attention and then disappear.  Front-end frameworks provide a great example of this: new ones pop up and exist for a few months before being superseded by other frameworks.

    Another example of technology followers is containers—few doubt their usefulness and most of us are convinced they are the best solution. The only question is which cluster orchestration framework to choose. These frameworks are evolving so rapidly, with new ones introduced on a weekly basis, that it’s almost certain most will be defunct within a year. So, if you are into experimenting with the latest offerings, chances are you could make a wrong choice. Will it be Kubernetes? Docker Swarm? Mesosphere Marathon? Rancher OS? Cloud Foundry’s Diego? CoreOS Fleet? The question is not whether to adopt one of those tools, but rather, which one has the best shelf life.

    Most of us fall under the third group, the technology hopefuls. We don’t have the ability to lead the way, nor do we have the luxury to explore the latest and greatest technologies. Yet, we cannot allow ourselves to become obsolete. The industry is moving so fast that just a few years can leave you at the back of the pack where no effort or investment can get you back in the game.

    The technology laggards are the software companies that have fallen behind. This group includes businesses that are struggling to remain intact and run the risk of disappearing. These are the organizations that do not innovate, do not adapt, do not invest (enough) in improvements and do not even understand the current industry trends. They are the organizations that do not comprehend that becoming obsolete doesn’t take decades, but years—sometimes even months.

    Based on the definitions of these groups, chances are, unless you are Google or Microsoft, you are not in the first or even second groups. By reading this article you are making the effort to be informed so you don’t lack the self-awareness that places you in the fourth group. Like most software organizations, you fall into the third group of technology hopefuls.

    As part of this group, you have to balance between the latest and the greatest technologies and the chance of becoming obsolete. You cannot try every new solution that comes along, nor you can let years pass by until you jump on the train. The big questions you have to ask are, How can I distinguish what will stay and what will disappear? How do I make a choice between what to adopt and what to ignore?

    There may not be a one-size-fits-all answer, but one process you absolutely cannot ignore is DevOps. If you’re asking yourself whether your organization should adopt DevOps, the answer is a resounding “yes.” And I encourage you to adopt it now, before you are replaced by other companies that are already living and breathing DevOps. Otherwise, you’ll be unable to adapt to the speed needed to keep up in today’s market and understand the cloud and scale accordingly when an avalanche of users come to your site after a successful marketing campaign. Lacking preparedness could cost you your business, especially in a competitive market.

    DevOps is here to stay, evolving similarly to Agile by providing value and answering many of today’s challenges. The only problem is that adopting DevOps can be difficult. To implement DevOps, you might have to change your company’s culture; you might need to adopt new tools; you might need to change processes; and, you might need to change your software architecture. Changing any of those aspects is hard, but changing all of them is very hard.

    Your culture and company structure need to be agile (in the literal meaning of the word). The old, monolithic tools need to be replaced with smaller, much more dynamic ones that will work well with the ever-changing nature of cloud infrastructure. Processes need to be automated, since there is no time to pause for manual intervention. To accommodate the needs of automation and frequent deployments, your applications and services will need to be relatively small for continuous delivery or deployment to become a standard process. Your teams need to be highly specialized and fully capable of working on all aspects of the software development life cycle, from requirements to post-production support.

    It’s a harsh and challenging road ahead, but at the end of it lies success. You’ll experience faster time to market, greater reliability, high availability and faster adaptability to market changes. Some are already there, while others already embarked on the journey. Don’t be left out—the alternative will leave you obsolete.

    To DevOps or not to DevOps is not the question. For most organizations, adopting DevOps is the answer.

    About the Author / Viktor Farcic

    viktorfarcicViktor Farcic is a Senior Consultant at CloudBees, a member of the Docker Captains group, and books author. He coded using a plethora of languages starting with Pascal (yes, he is old), Basic (before it got Visual prefix), ASP (before it got .Net suffix), C, C++, Perl, Python,ASP.Net, Visual Basic, C#, JavaScript, Java, Scala, etc. His big passions are Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD). He published “The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices,” and  “Test-Driven Java Development.” He is currently working on his third book, “The DevOps 2.1 Toolkit: Docker Swarm.” Connect with him on Twitter.

     

  • DevOps Dozen Finals Voting is Open!

    DevOps Dozen Finals Voting is Open!

    Sometimes, good things are worth waiting for. I am happy to say that the voting for the DevOps Dozen finals is now open! There are 12 Categories with up to 12 finalists in each category. All of the finalists came from nominations by you our audience. In fact that is why it took so long for us to come up with the finalist list. There were over 1000 nominations and due to our own fault, we had to tabulate by hand.  As a result we will keep voting open until November 18th.

    We will publish all of the finalists in a subsequent article, but the are all available on the voting site. Congrats to all of the finalists! In many of these categories, it is going to be very hard to choose who to vote for.

    You can only vote for one finalist in each category.

    Here are the categories:

    Best DevOps Open Source Project

    Best DevOps Commercial Solution

    Best DevOps Company Executive

    Most Effective DevOps Solution Provider

    Most Innovative DevOps Solution of the Year

    Top DevOps Evangelist

    Successful DevOps Transformation

    DevOps Transformation Executive of the Year

    Best New DevOps Solutions Company

    Best DevOps Book/eBook

    Best DevOps Presentation of the Year

    Best devopsy.kinsta.cloud Article of the Year

    Please only one vote per person and we will be enforcing this on the backend. Any questions please contact us at devopsdozen@devops.com.  If any of the finalists would like a badge to send people to vote please again contact us at devopsdozen@devops.com

    Lets hope we have less controversy and rancor than in our US Presidential elections and good luck to all of the finalists!

    — Alan Shimel

  • Infrastructure’s Impact on Shifting Left

    Infrastructure’s Impact on Shifting Left

    If you lead big honkin’ software development projects at a big honkin’ enterprise, you’re probably doing everything you can to shift QA left. That’s because the earlier you discover defects and shortfalls, the faster and less expensively you can bring great software to market.

    Unfortunately, above a certain scale, it takes more than just better processes and a more aggressive culture to shift test and QA left. It also requires a different approach to the infrastructure you use to distribute your builds.

    Infrastructure and the Problem of Scale

    Most software developers understand the scale issue primarily as one of complexity. The bigger the project, the greater the chance that something won’t work with something else exactly as planned.

    But large software projects also canget badly impeded by the sheer physics of build distribution.

    Take, for example, a 10GB build that you have to distribute to five different domestic and offshore locations from your primary facility over your company’s 10Mbps MPLS connection. If your two of your locations are domestic and have 5Mbps connections, it will take five hours to get them each build. If the other three are offshore and have 2Mbps connections, it will take them each 12.5 hours to get their copies of the build.

    That’s a “time tax” you’ll have to pay again and again as you keep having to ship massive files over the network to your globally distributed test/QA team. Worse yet, the more Agile and iterative you get, the more you keep paying this “time tax” over and over.

    So hours expand into days, and days into weeks—constantly frustrating even your best efforts to more aggressively shift left.

    Avoiding the Scale-Driven Time Tax

    Here’s how you can successfully avoid the time tax that chronically prevents you from shifting your biggest projects further left.

    Instead of continuing to use IT infrastructure that was never designed to support time-compressed software development at scale, you can instead implement a hub-and-spoke build distribution system that virtually eliminates network-related delays.

    This hub-and-spoke model lets you maintain a “gold copy” of your current build(s) in the cloud—while providing all your remote locations with their own local copies that get continuously and automatically updated with any changes as they occur.

    This model eliminates network-related bottlenecks while allowing your geographically dispersed teams to collaborate without tripping over each other’s work. As a result, you can shift left much more aggressively.

    Of course, infrastructure decisions typically aren’t made by the same folks who lead software development. So the two groups have to collaborate closely to make sure the network doesn’t impede critical development processes.

    But both parties have lots to gain—because hub-and-spoke saves infrastructure owners lots of money in storage, bandwidth costs and network acceleration hardware at the same time as it empowers development to shift further left.

    That’s why DevOps leaders and enterprise infrastructure owners need to work together ASAP. The digital success of the business depends on it!

    — Barry Phillips