devopsy.kinsta.cloud

Author: contributor

Why DevOps Needs Cloudified NPM

One of the three “ways”—or principles that DevOps guru Gene Kim articulates as defining DevOps—is amplifying feedback loops. One of the key ways that Ops contributes to this amplification is by implementing rich monitoring instrumentation of operational conditions. The move toward more automated configuration management and the rise of cloud-friendly application performance management suites have gone a long way to providing strong feedback loops. However, network performance monitoring (NPM) is sorely in need of cloudification to become relevant to DevOps.

In one of my previous articles on devopsy.kinsta.cloud, I wrote about the impact of DevOps on IT operations management, and noted that infrastructure management tools have largely lagged behind APM in terms of becoming cloudified and API-friendly. NPM is a case in point. Just to be clear on terms, by network performance monitoring, I’m talking about monitoring that collects metrics such as latency, TCP retransmits and out-of-order and fragmented packets. These four metrics can tell a network engineer a lot about whether the network is the root cause or a major contributing cause to application performance issues. Other metrics and data points that are highly relevant to NPM are interface utilization percentage, traffic flow statistics and, for any apps or services that rely on internet communications, BGP paths. These latter metrics and data sets help engineers locate underlying causes in the network, such as congestion on an interface, large spikes in flows, internet path changes or correlation of performance issues with traffic traversing a particular ISP’s network. Sounds great, right?

The problem is, the way these metrics have been collected is all wrong for DevOps practice. For the last two decades, NPM tools have fallen into two main buckets: free, manual tools such as TCPDUMP, MRTG and WireShark; and monolithic, siloed commercial tools. Nobody will ever dispute the value of free tools, but at a certain point, chasing problems around with manual tools just doesn’t scale, so sooner or later most NetOps organizations have to invest in commercial tools.

Commercial NPM tools were primarily architected in a pre-cloud, pre-DevOps era, when data centers all were inside the WAN, applications were centralized and monolithic and all users were somewhere else on the WAN in a campus or branch office. Metrics collection was performed by appliances via connecting to the span interfaces of major routers and switches at choke points—the junctures of LAN and WAN connectivity.

That era is disappearing rapidly. Most new applications are being built on a distributed basis, leveraging hybrid cloud. With distributed application components, there is a much more complex mesh of communications at play, much of which will cross networks and the internet. Further, in most cloud environments, you simply can’t deploy an appliance—not even a virtual one, since in many cases there simply are no span ports.

The problem with traditional NPM goes beyond a lack of fit with modern application architectures. NPM appliances are designed as vertically integrated systems with a GUI as the only real way to get data out of them. As a result, their APIs are usually at best second-class citizens. This is problematic for DevOps because amplifying the feedback loop means being able to serve meaningful real-world data up across different teams.

The cloud and DevOps gap in NPM is pronounced enough that major analyst firms have taken notice. In May of this year, Gartner analyst Sanjit Ganguli published a research note titled, “Network Performance Monitoring Tools Leave Gaps in Cloud Monitoring.” It’s a fairly biting critique of the NPM space that says, essentially, that the vast majority of current NPM approaches were largely built for a pre-cloud era, and are unable to because the new complexities brought by decentralization and full-stack virtualization. As a result, network managers are left in the lurch when trying to adapt to the realities of digital operations.

What is needed to cloudify NPM and make it DevOps-friendly? First of all, with distributed, hybrid cloud applications, there need to be options to embed NPM metric collection agents in cloud server deployments, either directly on app servers or load balancers such as NGINX or HAProxy. With container management and configuration automation tools, deploying lightweight NPM agents to more distributed points is very doable. By collecting NPM metrics on or very close to application servers, you get the most accurate read on “is it the network?” when app performance issues arise.

Another key aspect of cloudifying NPM is where the analytics happens. Appliances have severe compute and storage constraints. In the era of big data and cloud-scale compute economics, relying on appliances for NPM analytics is beyond outmoded. There are a plethora of open-source big data platforms as well as a growing number of emerging commercial SaaS options for NPM analytics. Today, big data network analytics platforms allow engineers to perform deep ad-hoc analyses on billion-row datasets and get answers in seconds.

DevOps’ mandate for amplifying the feedback loop plus the availability of copious cloud compute capacity means that there is no excuse to not aggressively measure everything, including network performance. Networking teams can and must go beyond config automation to change the way and the scale they gather and share metrics to server and app dev teams. Cloud-friendly NPM is a needed step to bring about Net DevOps as a lived reality in IT.

About the Author / Alex Henthorn-Iwane

Alex Henthorn-Iwane is the vice president of Marketing at Kentik. He has more than 20 years of experience bringing new technologies in networking, security and software to global markets. Henthorn-Iwane leads the global marketing strategy for Kentik and helps the company bring its story and solutions to network-dependent organizations around the world. Connect with him on LinkedIn, Twitter or SlideShare.

November 10, 2016
7 Best Practices for Continuous Delivery Success

Continuous delivery refers to the development of software in short and ongoing build-test-release cycles along the deployment pipeline. Repeated testing of processes and scripts before deployment to production means most errors are discovered early on and have minimal impact. Plus, finding and fixing such errors is much easier with fewer changes per release—software is released faster and more frequently with fewer deployment problems due to a heavy focus on visibility, instant feedback and incremental changes.

To accomplish this, companies must have a straightforward and repeatable deployment process. Most reliable, of course, is an automated deployment pipeline that can feed into any environment.

We have identified seven continuous delivery best practices that are supported by a set of complementary task-specific tools, in what’s known as the “DevOps toolchain,” to automate the process from end to end and minimize human error.

Version-Control Everything

The native code deployment process generally includes a built-in safety net, preventing out-of-process, locally generated artifacts from entering the production environment. Every change a developer makes must be documented in the source control repository or it is not included in the build process. If a developer copies an artifact generated locally to a test environment, the next deployment will override this out-of-process change.

This insistence on having a single source of truth—and a reliable one—creates a stable foundation for all development processes. However, the processes are only as strong as their weakest link. That’s why the primary golden rule for effective continuous delivery is to version-control everything. What works well for code also will preserve the integrity of configuration, scripts, databases, website html and even documentation.

Build Binaries Once

Not every organization’s build process is the same or uses the same tools, but every build process in a single organization must be completely consistent. Whether the build is a single file deployed to an automated test environment or a complex build with several different possible deployment versions, each build version should happen exactly the same way and result in unique binary artifacts.

This one-time-only compiling eliminates the risk of untracked differences due to various deployment environments, third-party libraries or different compilation contexts or configurations that will result in an unstable or unpredictable release. Save the compilation phase output (the binaries) to a binary repository, from which the deployment process can retrieve the relevant artifacts.

Deploy the Same Way Every Time

An inconsistent deployment process can become a source of configuration drift across environments, especially with the rapid releases common in a continuous delivery system. As a result, valuable time and effort are wasted in identifying and addressing difficulties arising from the application working in one environment and not another.

For a reliable process in all environments, then, the same set of steps must be repeated from start to finish. This ensures the same results in lower environments, with more frequent deployments (such as integration, QA, etc.), as in higher environments (pre-production and production), with fewer deployments.

Smoke Test

Smoke testing deployments is a very rapid way to make sure that the most crucial functions of a program work and will pass basic diagnostics. This non-exhaustive software testing (of all elements, such as services, database, messaging bus, external services, etc.) does not provide the same fine-grain comprehensiveness as full test suites; however, it can be run frequently and quickly, often in a matter minutes (rather than hours or days). This allows for a much quicker turnaround on what can become very time-consuming and basic issues.

The faster the feedback loop works (especially with automated test tools such as Telerik, QTP, TestComplete), the higher the final product’s quality will be and the quicker it will reach its release-ready state.

Deploy into a Production-like Environment

Each new deployment (using, for example, IBM uDeploy, CA Release Automation, XebiaLabs, Automic) should be made into an environment that mimics as closely as possible the actual final production environment. This includes infrastructure, operating system, databases, patches, network topology, firewalls and configuration. By validating software changes in this type of detailed pre-production environment, mismatches and last-minute surprises can be effectively eliminated and applications can be released safely to production at any time.

Instant Propagation

Continuous delivery by definition must be an ongoing process of building, testing and releasing. Every check-in to a source control repository should trigger compiling (if needed) and packaging by a build server. This, in turn, should automatically initiate certain predefined testing until the software can either be marked as releasable or returned to development.

Continuous integration tools (e.g., Jenkins / CloudBees, Bamboo, TeamCity) ensure that cascade of actions along the delivery pipeline is consistent, automatic and instant. Thus, development teams merge developed code and get feedback from automated test tools many times a day, for a more efficient deployment and update process.

Include the Database

No list of continuous delivery best practices would be complete without advising that the database be managed using the same basic protocols that ensure secure and reliable source code, task, configuration, build and deployment management. However, many times this is neglected because the database is unlike other software components or compiled code that are easily copied from development to testing to production. Yet, the database is actually a repository of the most valued and irreplaceable asset—our data—and preserving it accurately is imperative to continuous delivery.

Although the database poses several unique challenges, specialized database tools such as enforced database source control (for all environments), a database build automation tool and database release and verification processes can ensure a stable resource in your DevOps chain.

Considering these seven continuous delivery best practices will allow you to create a deployment pipeline with increased productivity, faster time to market, reduced risk and increased quality.

The key to ensuring a quick, robust and accurately repeatable continuous delivery is, as we have seen, automation, deployment consistency, comprehensive testing and database version control. With these fail-safes in place, pushing the “release to production” button can be done much more often and with much more confidence.

About the Author / Yaniv Yehuda

Yaniv Yehuda is the co-founder and CTO of DBmaestro, an enterprise software development company focusing on database development and deployment technologies. Yaniv is a DevOps expert who spent the last couple of years raising awareness about the challenges surrounding database development and deployment, and how to support database continuous delivery. Connect with him on LinkedIn and Twitter.

November 9, 2016
Moving to the Cloud? Consider These Questions

The cloud is going mainstream. That’s the word from a recent Cisco Systems-sponsored study, which found that more than two-thirds of organizations are using the cloud to “help drive business outcomes”—a whopping 61 percent increase from the previous year’s study. But almost the same number aren’t maximizing the true value of cloud computing.

What does this mean for your business? It means that while the cloud is quickly becoming a necessity rather than “nice to have,” it’s worth asking some hard questions before you make the move. You can get the most from your deployment after determining the answers to these five questions, and even more from the accompanying infographic.

What’s the Line-of-Business Benefit?

You’re not just moving to the cloud because everyone else is doing it; you’re looking for benefits that boost your bottom line. The notion such benefits exist is not just hype: Many companies report lower IT spending and increased agility in the cloud. Before you make the move, however, it’s worth asking about the specific line-of-business (LOB) benefits you hope to achieve. Otherwise, you’re putting the cart before the horse, hoping a cloud deployment will inspire some kind of revolutionary use. One firm directly tapped the benefit of agile cloud computing by writing a script that closed down sandbox testing environments at night and spun them back up again in the morning, saving tens of thousands per year. This exemplifies the true value of using cloud resources—but it doesn’t just happen. Find your need, and then tap the cloud.

Are You Ready for Change?

Is your company ready for IT transformation? Ultimately, that’s the role of the cloud—70 percent of businesses say the cloud has enabled them to re-engineer one or more business processes. Consider analytics. Running data analytics is the fastest-growing activity in the cloud, since companies now can “flip a switch” and start mining critical data sources.

Having the data on hand isn’t enough, however. Your company must be ready to run with this information and move forward with real change if you want to get the most from your cloud deployment. Put simply, the cloud is disruptive—embracing change is a requirement for increased ROI.

How Much Can You See?

Cloud providers promise on-demand, anytime, anywhere access. While it is a good thing for remote workers and satellite offices in different time zones, it also can lead to a problem: visibility. Do you know who’s spinning up new services, when and for how long? Do you have a way to track and monitor cloud uptime and performance to ensure your provider is living up to its service-level agreement (SLA)? Expert advice says it’s essential that you have a way to independently verify your company usage once services are hosted in the cloud. This could take the form of local monitor tools, third-party services or even a secondary cloud solution tasked exclusively with providing visibility. Bottom line? What you can’t see, you can’t measure—in turn potentially limiting your total cloud benefit.

Where Does Compliance Live?

You have compliance obligations. Maybe those obligations are related to consumer credit data, health information or legal documentation you’re required to protect. Whatever the case, if your cloud provider doesn’t comply with local or federal laws, you could face a hefty fine or other penalty. As a result, it’s worth tracking down a cloud provider that not only knows your industry standards inside and out, but also clearly describes in the SLA how these standards will be met. Here’s the takeaway: Always ask your cloud provider about compliance, and never settle for vague answers or promises that aren’t in writing.

Is Data Done Right?

How much data do you plan to store in the cloud? Almost 50 percent of companies now store more than half of their data in the cloud. Expect this number to rapidly increase as the cost of storage comes down year over year. Beyond balancing the need for local and cloud-based storage, however, it’s worth asking tougher questions about portability, backup and security. If you change providers, is your data ready to make the switch immediately? Is your cloud provider charging extra for data backup? If so, what does the service entail? Last but never least: What steps are being taken by your provider to safeguard data—both stored and in transit? Never underestimate the value of doing data right; better to pay more for great service than save a few bucks on cheaper, less robust alternatives.

The cloud has arrived. Before making your move, however, consider the LOB benefit, your readiness for change and ability to monitor services—along with your provider’s compliance and data-handling aptitude. To better understand the potential benefits of using the cloud, check out the accompanying infographic and determine the answers to a few more questions about how your company and cloud capabilities will fit together.

About the Author / Adam Cady

Adam Cady is director of third-party managed Sservices at SingleHop. Cady is responsible for developing cutting-edge managed services solutions and software management tools for hyperscale cloud platforms. Connect with him on LinkedIn and Twitter.

November 9, 2016
Will Blockchain Move Past Hype to Reality?

Blockchain has hit peak “hype,” according to Gartner’s recently published “Hype Cycle for Emerging Technologies.” The financial world has been very optimistic about blockchain or distributed ledger technology (DLT)—the underlying technology behind bitcoin—and the impending disruption it can bring to the way the financial system works.

Although the initial buzz around bitcoin has gradually died down over the last couple of years, DLT has gained a lot of traction in the industry. As a concept, distributed ledger and open network with encrypted data brings vast opportunities for ideation. But will it only be hype? Or will blockchain graduate from the lab environment to the real world? Only time will tell, but the idea of distributed ledger is here to stay.

From Idea to Adoption

Any new technology will go through its hype cycle before settling down with the complex reality of business adoption. Blockchain is most likely going through the cycle at this point in time. It may not be panacea for all the challenges faced by the industry today, but it definitely shows some initial promise of being a game-changer.

We have very rarely seen industry cooperation like this for a new technology. Financial institutions are excited and rightly so. Global financial markets potentially can save as much as $80 billion in operating costs if blockchain becomes a mainstream technology.

The application of blockchain will exceed hype only when it addresses the core issues financial institutions face today: simplification and security. While cost takeout is a great value proposition, I believe that adoption of blockchain as a technology fundamentally should revolve around rationalizing the process value chain and providing robust security. Some of the initial use cases for financial services firms show a lot of promise, from the process simplification and digitization perspective leveraging distributed ledger, but there is still significant ground to cover before it becomes real.

Why Blockchain Isn’t There Yet

There is exciting amount of exploratory traction around blockchain use cases, but the reality is that no financial institution has yet implemented blockchain in production, and I don’t think it’s going to happen anytime soon.

The success of blockchain as a technology hinges on three factors:

Security – Recent lapses in bitcoin exchange and virtual robberies of digital money pose a significant threat to the underlying technology (blockchain itself). In a world where each participant will have his or her own private key, there will be many hurdles to cross in the barriers of data security. How safe will it be? How quickly will it scale up to expose all the vulnerabilities?

Dealing with legacy – Many technologies have matured over the years, yet banks still run on mainframes! How blockchain interoperates with the legacy infrastructure in banks will be the most important aspect to watch out for. Is the idea to build a greenfield environment and re-imagine the financial world more pragmatic?

Trust – Data ownership traditionally has been a source of power. Digital currency and federated data over blockchain will change the very existence of political hierarchies. How will businesses deal with it?

Still, it’s a good bet to have in your long-term portfolio.

Bill Gates once said, “we always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next 10. Don’t let yourself be lulled into inaction.”

Although its foundational blocks are really solid, blockhain’s mainstream adoption in the near future is going to be tough. Hawk-eyed regulators will be picky about security threats and any negative news. But the collaboration on this technology is unprecedented and bodes well for the future, so I’m optimistic blockchain will become a reality at some point in time. Going by the wisdom of Bill Gates, I’m looking at five to seven years.

About the Author / Mohit Sinha

Mohit Sinha is a client partner in the Finance Solutions group at Wipro Digital and currently manages the relationship with a top tier Investment Bank in London. He has over 14 years of experience spanning domain consulting and client relationship management in the Investment Banking and Wealth Management domain. He has been part of successful delivery of transformation initiatives across UK and Europe CIB and PWM, Derivatives Operations, SEPA transformation and CIB/PB Order and Trade Management areas. Connect with him on LinkedIn and Twitter.

November 8, 2016
How to Bridge the Developer Gap

It’s time to bring cloud application development back into the organization and bridge the developer gap by training your own people.

For years, companies have outsourced many IT functions, treating computing as a commodity, perhaps thanks in large part to Nick Carr’s publication, “IT Doesn’t Matter.” Carr predicted that computing would become a utility. And while spinning up new servers in the cloud might be almost as simple as switching on a light, the functions specific to your business—your competitive DNA—aren’t flipping on automatically. Not even close.

Computing is not a commodity. It’s the cognitive engine of your business. The companies that are killing it right now view their computing environments the way we look at the human brain and nervous system. Their businesses generate, collect and process signals, and act on the intelligence influenced by those signals. Case in point: GE is building its own operating system—a central nervous system for its industrial applications. This is large-scale cognition.

You would not outsource your brain or spinal cord. You couldn’t survive without those crucial components of your overall nervous system. Yet for decades, companies outsourced key functions—technology and processes for understanding their businesses—because they didn’t think of technology as a core competency.

Now that they’re bringing it back in-house, companies are faced with another problem: a looming developer gap. The majority (64 percent) of IT professionals and executives taking part in the Cloud Foundry’s 2016 Identifying the Developer Gap report agreed that the developer shortage is a real threat. Most respondents (57 percent) state that this shortage has already impacted their ability to hire skilled people.

Every new technology comes with a labor gap. The way to close the cloud application skills gap is to bring the knowledge back into the organization—to train people who are part of the central nervous system of your business.

Business computing in the digital world is not just a faster way to process paper. When you think of your organization as an organism and integrate intelligence from all its parts, you behave more intelligently. Building apps to enable that integration is the difference between treating computing as a commodity vs. cognition.

Our study showed that by a nearly 2:1 margin, companies are choosing training over hiring or outsourcing as the preferred method for addressing a shortage of skills in their own companies. I have had multiple conversations with CIOs in the last two months in which they have said, “We have this working with a team of 40 developers. Now we need to make it work for 1,000. We aim to certify over 200,000 developers on Cloud Foundry in the next three years.”

The best way to bridge this developer gap is to train your own people. Think of them as essential parts of the whole. Enable them to use technology to adapt and streamline your business so you can compete in the digital world.

About the Author / Sam Ramji

Sam Ramji is CEO of the Cloud Foundry Foundation. A 20-year veteran of the Silicon Valley and Seattle technology scenes, Sam brings a wealth of business, product and open source experience to the foundation. He was head of strategy for API powerhouse Apigee, designed and led Microsoft’s open source strategy, and drove product strategy for BEA WebLogic Integration. Previously he held a range of software engineering positions at firms including Broderbund, Fair Isaac and Ofoto. He is a member of multiple industry advisory boards and volunteers with the Sierra Club. Sam is happiest in the mountains, where he loves to hike, run and play with his dog. In his spare time, he likes to play guitar, read fantasy and sci-fi novels, and spend time with his wife. Connect with him on Twitter.

November 7, 2016
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

Mehdi 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.

November 4, 2016
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 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.
November 3, 2016
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

Viktor 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.

November 1, 2016
7 Strategies for Continuous Delivery and Deployment Success

One of the key advantages of cloud-native applications is the ability to quickly push updates into production for specific microservices—giving developers the ability to respond rapidly to changing business requirements without having to upgrade the entire application. Successfully doing this requires far more than just leveraging a continuous delivery platform. Everything from the culture of the development group to the type of testing required to the underlying platform it will run on is critical.

Based on applying DevOps principles across several projects to date, I have found that development teams can benefit from following these seven key strategies before launching continuous delivery and deployment initiatives. By doing so, you’ll increase your opportunity for success.

Culture

Just having the right tools and technology isn’t enough in today’s enterprises. Successfully adopting an agile, continuous delivery and deployment process will require a culture shift within most development shops. Developers are no longer responsible only for their code; they must take full ownership of the development, testing, automation tools and, most importantly, building operational capabilities into the pipeline so the move to production is easier. Getting developers and the operations team on board with this may take some time and training, but the effort is critical, and your projects won’t succeed without this.

Automation Platform

Carefully consider the tool you’ll use for your continuous delivery pipeline because the current tools on the market have different optimal use cases. For example, if you need to do A/B testing you’ll want a tool that has capabilities for phasing the rollout based on the test results. If your application requires multiple updates in a short time span, you’ll need a tool that has advanced release management capabilities including good pipeline visualization and support for the management of cloud environments.

App Architecture

Design your applications so they are cloud-native. This is typically associated with microservices and containers and will enable you to independently and frequently update each service independently. The typical stages of a deployment pipeline are build, unit testing, integration testing (including functional testing), API testing, performance and staging, then, finally, on to production. However, with microservice architectures and advanced deployment techniques, more and more customers are bypassing certain stages and testing in production, albeit very contained production environments.

Each stage also can include the creation of dynamic environments in the cloud, enabling the stage itself to be provisioned, executed and decommissioned as a part of the pipeline. If you choose to do this, look for a tool that has a number of built-in cloud plugins, so creating and destroying environments in AWS, Google Cloud and other clouds can be done easily.

The application and infrastructure stack for each microservice also should be specified. This could include the application Jar file, a Docker file, or server image such as an AMI; any related services such as AWS Lambda functions; and all configurations and policies. These specifications all should be managed in an infrastructure-as-code manifest, which ensures versioning, consistency, change auditing and testing. It also ensures that the build resources, such as baked images, JARs and AWS Lambda functions, are consistently passed to each stage of the pipeline, from testing to production, eliminating the risk of imposing inconsistent environments and configurations. An AWS CloudFormation template is an example of an infrastructure-as-code manifest.

Security

Security is a necessity in the world of increasing threats that we live in; however, the common approach of waiting to test security right before the push to production is the wrong approach. Security should be built in to the pipeline itself and automated as part of the DevOps CI/CD process. It’s essential to validate the building blocks without slowing down the process. For example, leading companies are automating code scanning, template checking and other security tests in within the phases of the pipeline itself.

Insight

Visualizing and tracking pipelines, environment variables, test results, versions, issues and other artifacts allows developers and the operations team to share a common view throughout the project life cycle. This improves collaboration and traceability.

Delivery Strategies

Automating tests is critical to pipeline design and delivery. Without comprehensive, high-quality, fully automated tests of the deployment pipeline, production failures will occur. Code coverage no longer is a good representation of code quality. In the cloud-native world, test cases and test suites need to be mapped to functionality and business outcomes desired to ensure that the test team gives the green light and then everything goes red in production. In situations where time limitations prevent a comprehensive approach, first automate the critical capabilities and flows, then assess the cost-benefit of automating additional tests.

Be sure that the data and environment for testing and automating purposes mirrors the production data and environment as closely as possible. Most pipelines have a “pre-production” stage before pushing software into production. You may consider building multiple stages across multiple AWS regions before pushing the software to production.

If your goal is to update software in production very frequently and without any downtime, make sure your pipeline tool can easily manage multi-region deployments, such as blue/green and canary deployments for server groups and clusters across AWS and other public infrastructure-as-a-service (IaaS) clouds.

Monitoring and Feedback

Finally, it is essential to get continuous feedback on the user experience, response times, performance of key business services, and the technical metrics from all stages of the life cycle—development, QA and production. Only through this continuous feedback can you ensure that no degradation occurs as you push out releases with increasing frequency. This too needs to be built into each phase of the pipeline to understand performance and improve things earlier in the process, where it costs much less.

There’s no doubt that a successful continuous development and deployment process can deliver significant benefits to users, who constantly require new and enhanced capabilities and can’t wait the weeks or months that a traditional development cycle requires By carefully considering these seven strategies, your projects will benefit from reduced application errors, less downtime and much happier users.

About the Author / David Cramer

David Cramer is vice president of Product Management for the Cloud/DCA business unit at BMC. Prior to BMC, David was head of product management for CA Technologies. During his tenure at CA, David was responsible for application delivery, cloud management, virtualization and Infrastructure automation solutions. Before joining CA, David held executive positions at AlterPoint, Motive, NetSolve and Nortel Networks. David’s focus is on continuous delivery, cloud management and web-scale IT. David received his MBA from Southern Methodist University and a BS in Finance from Georgia State University. Connect with him on LinkedIn and Twitter.

October 28, 2016
Migrating to GitHub
In recent months, Newt Global Consulting migrated multiple source code repositories to GitHub. The repositories are anywhere from 10MB to few Gigabytes of source code. This blog is to share our experiences in migrating source code from SVN and AccuRev to GitHub. Most of the material below should be valid for any Git repositories.

We used 100 percent open-source tools that are freely available, and we developed the process that fits our needs. Thank you very much for the authors of these tools; without them, we couldn’t have done it. Long live open-source community and may the day never come when machines code!

This article is mainly focused on executing migration; best practices or branching strategies for GitHub are not in the scope.

Before diving into migration, here are some of the motivators we observed that are steering organizations away from traditional source code repositories:
- Managers and architects like the distributed and offline feature of GitHub.
- Enforces discipline on developer’s part (less excuses of dependency—you have local copy of everything, intelligent merging of GitHub, etc.).
- Technical-savvy groups already are using GitHub (Git Bridges).
- Developers hate the change in the beginning but they are quick learners and like to adapt with rest of the industry.
- Integration with other DevOps toolkits is a motivator (ex: Webhooks).
- Naturally fits with open-source software development (easily extend and contribute).
- Enterprise-level groups are pushing the change (playing catchup with individual development groups and the rest of the industry).
- File size limitation of GitHub is forcing the use of binary repositories and security teams like it, as they can now monitor the large open-source libraries spread across the org.
SVN to GitHub Migration

There is plenty of material on the web about the difference between SVN and GitHub. I suggest that you go through them (if you have to). Here are few links that we found interesting:
- Branching differences between SVN and GitHub: http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-thanin-svn
- If you are fan of SVN, check out the following for the greatness of SVN: https://svnvsgit.com/
Prerequisites
- Get read-only user access for SVN repository.
- Make sure “gitsvn” utility is available in local environment.
- Download svn-migration-scripts.jar from https://bitbucket.org/atlassian/svn-migrationscripts/
  downloads
- Refer to the following URL for more documentation on the above script: https://www.atlassian.com/git/tutorials/migrating-prepare/
- Decide on GitHub organization name, team name and members who will be part of the team.
- Set up the organization.
- Set up the team and assign team members.
- Create a repository to push the code from your work area.
Migration
- Extract the users information from SVN java -jar svn-migration-scripts.jar authors <SVN Repo URL> > authors.txt
- Clone the SVN Repository git svn clone –stdlayout –authors-file=authors.txt <SVN Repo URL> <GitHub Repo
  Name>
- Create connectivity to remote repository git remote add origin <GitHub Repo URL>
- Push the code from local to remote repo git push –u origin master
- Converting remote braches to local repo java -Dfile.encoding=utf-8 -jar svn-migration-scripts.jar clean-git –force
- Push all the changes to remote repo git push –all
Noteworthy
- We ran the scripts on Linux (case-sensitive file system); OS X has additional steps to follow (refer: https://www.atlassian.com/git/tutorials/migrating-prepare/)
- If SVN instances have local user IDs defined (not SSO), the authors file created is not of use. But you need this file to successfully to run the scripts.
- Incremental migration is possible, but we scheduled weekly jobs for full migration during the transition phase.
- Full migration takes time; try to avoid network delays. For us, our 300MB repo took around four to six hours.
- In some cases, we had to clone the SVN repo to our local file system due to access issues.
AccuRev to GitHub Migration

AccuRev is a centralized version control system developed by Borland (now Micro Focus). It uses client-server architecture and preparatory technology, and so it’s a bit tricky to extract code for full migration. We used the ac2git utility developed by Navico—the tool does the heavy lifting but took few iterations and bit of tweaking to fit our need. Most of the difficulty was in understanding how AccRev works and the relative mapping to GitHub.

Prerequisites
- Install python 3.4, Git-Bash version 2.7.4 and AccuRev
- Make sure the paths to the AccuRev and git executables are correct for your machine, and git default configuration has been set
- Clone the ac2git repo from the https://github.com/NavicoOS/ac2git
- Run python ac2git.py –help to see all the options (strongly recommend you do this)
- Run python ac2git.py –example-config to get an example configuration
- Strictly follow the steps outlined in the “How to Use” section; otherwise, you will be forced after few failed attempts
Migration
- Make an example config file:
  - python ac2git.py –example-config
- Modify the generated file ac2git.config.example.xml, (there are plenty of notes in the file and it is time to run –help option if you have not done it as advised in prerequisites)
- Rename the ac2git.config.example.xml file as ac2git.config.xml
- Modify the configuration file and add the following information:
  - Set accurev username & password
  - Name the depot. Map each depot to single Git repository. Run the script for each depot separately
  - Running the script for multiple depots to single folder overrides all depot streams into same folder. Scripts fail when given multiple folders, so always run the script for one depot at a time
  - Create an empty folder and provide the complete path in the config xml file. The folder must exist and preferably should be empty
  - There is no concept of having same folder name as stream name. There just needs to be an empty folder where all the contents of stream will store
  - Start & end transactions which correspond to what you would enter in the accurev hist command as the<time-spec> (the keyword highest or the keyword now)
  - If the start-transaction and the end-transaction are time-spec, the script will fetch the data and history only within this time period. For example start-transaction = “2013-02-07 13:41:17” and endtransaction=
    “2014-02-07 13:41:17”
  - Use “highest” keyword instead of using “now” in end-transaction
    
    “now” will fetch data until the date and if there was some history deleted from workspace or not promoted from other streams than “now” keyword will not work
    
    “highest” keyword always look for the latest and highest commit history (preferred option)
  - User mapping from Accurev to GitHub. Hint: Run accurev show -fi users to see a list of all the users
  - Choose the preferred method for converting the streams
    
    Recommend ”deep-hist” method for sparse streams (transactions that have changed the stream contents are far apart)
    
    Recommend “diff” method for regular streams (when in doubt, just use “deep-hist”.)
  - Run the script
    
    python ac2git.py
  - If you encounter any trouble, run the script with the –help flag for more options.
Noteworthy
- The stream must always have some history. The script did not work for us when no history was available.
- If there are any duplicate or missing usernames, make sure to use the corresponding parameter. We ended up changing the script to handle duplicate users (this is not needed if you use the right parameters).
- In GetMissingUsers(config) method of ac2git.py code, comment last two lines
  - # if not found:
  - # missingList.append(user)
- Migration takes time, try to avoid network delays. For us, a 300MB repo took around six to eight hours.
- We have not tried incremental migration—we scheduled a weekly full migration and cut over all the users over a long weekend.
Conclusion

Overall, the experience was very rewarding, not only in assembling the right toolkit but process-wise as well. Every organization has its own methodology when comes to source code management and how it promotes code (branching strategy). We found small-to-medium-size enterprises have much more mature process than some of the large enterprises, though they are catching up fast.
- Don’t expect large enterprises have centrally managed source code repos (SVN hosted in some sharable desktop under manager’s desk).
- Difficult to get developers to think distributed mindset (why should I clone the entire repo?).
- Working closely with Enterprise GitHub helped in reassuring clients.
- Most of developers like to use IDE plugins than command line or web client.
- Prepare to answer backup, HA and DR-related questions.
- Enterprise GitHub comes as virtual appliance not application—prepare yourself to deal with infrastructure groups on deploying VMs into production.
- Some application groups preferred lift and shift mode than migration; don’t get shocked when they say “don’t care about history” (typically these are small dev groups).
- Integrated Slack with GitHub—this was hit not only with developers but also leadership.
- Extended Hygeia dashboard to provide team level analytics for leadership view.
About the Author / Sridhar Peddinti

Sridhar Peddinti is vice president, DevOps and Cloud practice at Newt Global Consulting. He is a 20-year technology and business leader with global experience in executing large scale projects across multiple industry verticals. He champions the consulting space helping customers with complex problems and providing them with DevOps and Cloud strategy. He has extensive hands on experience in process improvements using combination of tools kits and migrating number of legacy systems to Cloud and related technologies. Connect with him on LinkedIn and Twitter.
October 27, 2016