devopsy.kinsta.cloud

Author: contributor

DevOps across the Enterprise: Fostering Cross-Functional Collaboration
DevOps practices originated at startups, where nimble Development and Operations teams pioneered the concept of cross-functional collaboration to speed up software release cycles. By 2009, DevOps became a recognized industry practice: a software development methodology that promised higher velocity for enterprises working to get products to market more quickly. Many enterprises have since embraced DevOps among their software development teams, and early adopters are now taking it beyond code to other parts of their organization.

Unfortunately, successful cross-organization collaboration is uncommon outside of Dev and Ops teams. With the Internet of Things bringing software and hardware together in previously disconnected devices and industries, collaboration among design, development and product management teams has become crucial. There are technical, procedural and cultural challenges which must be addressed to bring the same level of DevOps success to other areas of an organization.

The State of Collaboration

An important place to start is understanding the interactions between different groups in an organization.

Consider one of the most frustrating areas of the software release process prior to DevOps-style collaboration. Builds would be “tossed over the wall” from Development to Quality Assurance, and then from Quality Assurance to Operations, with each team moving on to other things as soon as a build was handed over. Visibility into the overall status of the project was non-existent.

When other departments collaborate, what is the level of visibility into the work being produced by the groups that depend on one another? Does marketing know if the latest feature made it past the initial legal review and the likelihood of it being included in the final product? The answer is usually no; there is little visibility into the process and decisions are shared close to project deadlines. Applying DevOps practices to an organization’s entire product pipeline changes the collaboration paradigm, expediting time to market and improving overall quality.

Culture, Automation, Measurement and Sharing (CAMS)

CAMS is relevant when both technical and non-technical teams collaborate. As seemingly unrelated teams are required to work together, it’s important that they have a culture of shared accountability.

Skipping the details of specific tools and technologies, one key consideration for organizations to recognize is that automation is crucial to a repeatable process, enabling speed and scale. It also provides a high level of visibility, as it’s closely coupled with the sharing of data. When only one team is manually updating metrics, communicating what’s going on is manageable. But what happens when other groups are dependent on work being produced by a group that’s updating its data manually? What if multiple groups depend on knowing the status of a task in a timely manner? Manual processes result in an endless flood of phone calls, emails or instant messages asking if information is up to date.

The measurement aspect of DevOps opens up a can of worms. It’s important not only to determine what should be measured but also to have a common way of discussing how it’s being measured. Establishing a common vocabulary across an organization for day-to-day tasks can be extremely difficult.

In these situations, it is important to go back to the core benefits of trying to bring the DevOps style of collaboration to other groups in an organization.
1. What is the desired business outcome?
2. Why don’t current processes meet requirements?
3. How could change positively benefit employees’ daily work?
As people become comfortable with “why,” discussions of “how” become easier.

Once changes are underway, it’s important to make sure that there is a single place where people can obtain accurate status updates and share information. Bringing DevOps into the enterprise takes time, but providing visibility into any project in an automated, transparent manner will show the positive impact of sharing information in a timely way.

Most importantly, try to quickly demonstrate success—however small. There will be roadblocks, political objections (an unfortunate reality) and people who just don’t want to change. But by measuring and demonstrating success and tying it back to business outcomes, you will set up your organization for success.

Like many other initiatives, the key to a successful DevOps program is intention. To drive this home, an old joke: how many therapists does it take to change a lightbulb? Just one. But it has to really want to change.

About the Author/Jonathan Thorpe

Jonathan Thorpe, Technical Marketing Manager, Perforce Software –Before joining Perforce as a Technical Marketing Manager focused on Continuous Delivery and DevOps, Jonathan Thorpe held technical marketing roles at CFEngine, Serena, and Electric Cloud, where he specialized in DevOps culture and automation technologies. In his spare time you can find him reading, playing with all of the current video game consoles, dabbling with mobile software development, and playing with the Raspberry Pi.
April 10, 2015
To Get Jammin’ Mobile Downloads, Toss Out 40 Years of Tradition

The tally of smartphone usage worldwide is mind-numbing: Even as far back as 2012, more people on earth had access to a mobile phone than had access to a toothbrush. Even more mind-numbing must be the stats on the untold millions of those mobile device users in various states of rage at any moment while waiting for their content to finish downloading. Mary Meeker’s 2014 “State of the Web” report states 30% of all mobile phones are smartphones. The usage of the smartphones is growing in a compounded manner.

I’m confident that my own frustration resonates with those millions of users. And it’s only getting worse. I think about the plight of the next N billion mobile users who will depend on constantly overburdened mobile networks in all parts of the world.

I was fortunate in being able to turn that frustration into a mission, when I founded PacketZoom. I had developed the blueprint of an idea for a remedy while working at Google, and then spent two years to productize and trial the technology in the heavy R&D phase of PacketZoom starting in 2013. But we weren’t content to tweak the existing protocols to save a few milliseconds here and there – and neither were countless app developers around the world, who faced the same conundrum. Why not? Stats have proven that mobile downloads taking more than six seconds cause about half the users to defect from the app they are using – unaware that the network, and not the app, is to blame. And it’s well past time for incremental approaches to fixing the problem. [citation: https://blog.kissmetrics.com/loading-time/]

The turning point for me was my first-hand experience on a trip to India while trying to load the first screen of an application while on a moving subway. Only an exercise in extreme restraint prevented me from bludgeoning my phone – which, of course, was not the culprit. Clearly, the problem was unsolvable using the prevailing technology that had been jury-rigged over 40 years to serve every new use-case that came along. Maybe that time-honored, but worn-out technology had to be replaced!

The last few years we have seen an explosion of apps on mobile phones. The next few years promise to bring an order of magnitude larger number of devices in response to the “Internet of Things” phenomenon. If we continue using the same old protocols, the interminable waits for mobile content will become intolerable.

Time to Lose Four Decades of Losses

So what exactly is the problem with the legacy protocols? After all, they’ve been made to work for today’s use cases. Well, allow me to explain.

Let’s start with IP (Internet Protocol). IP addresses were intended to be solidly and reliably attached to a computer forever, in the same way a street address is solidly and reliably attached to each house. (And note that a smart phone is just another computer.) A packet sent to that address could go to only one place (the one house – or, in our analogy, the one computer). But now, in the year 2015, the IP address is but an ephemeral property of a mobile device. It’s as if everyone lives in a van now and your address depends on where you parked your van at the end of any day.

Today, the IP address of your mobile device might change while you walk from your office to the parking lot. As you move from your office WiFi to the LTE connection outside your office, and as you move through myriad disconnections and reconnections while travelling in personal or public transportation, you can be “taking” and “releasing” dozens of IP addresses during the course of your commute.

The upshot is, that when an app on your mobile device starts communicating with the cloud, every change of IP address causes the app to initiate the communication from the beginning – a so-called “cold start”), rather than from the point where the previous communication paused at the point of disconnection. That’s one very big problem, resulting in time lost through duplication of transmissions.

What’s more, each new reconnection to the network requires establishing a new TCP session, a session that utilizes the 40-year-old technology, TCP (or Transport Communications Protocol). But guess what? Each new TCP session starts cold and, according to the TCP algorithm, has to gently ramp up to full speed every single time. And the lost time due to those delays adds to the lost time created by continuous disconnections and reconnections that occur in all mobile environments.

TCP has been honed over the years to work “tolerably well” for general use over all possible kinds of networks. It was originally designed to connect huge computers, administered by professional sysadmins, and housed in meticulously maintained facilities with triple redundant power. It does the job that its least-common-denominator design is expected to do – that is, to get a stream of data from one computer to another (i.e., from one IP address to another) reliably.

Those are the guarantees of the TCP protocol. What it doesn’t guarantee however, and doesn’t even address, is speed. It uses the most conservative method possible to get your data packets from one place to another. As a result, user-level protocols (e.g., HTTP) get cluttered with hacks atop other hacks to try to work around TCP’s lack of concern for speed.

Consign TCP and HTTP to Their Rightful Place

Now imagine this conversation from sometime in the early 2000’s among boffin from companies making web browsers:

Boffin A: “TCP doesn’t allow us to use the full available bandwidth of the available channel (DSL, dial-up, or those new-fangled cable modems.”

Boffin B: “No problem! How about we open six TCP connections at the same time. Let them fight it out among each other.”

Boffin A: “Done.”

Boffin B: “We’re geniuses!”

Well, in fact, web browsers have been built around this approach ever since that ill-fated day. But the web runs on Hypertext Transport Protocol, aka HTTP, version 1.1 for the last decade and a half! HTTP, as an application-level protocol, knows nothing about speed either. And so browser vendors, over the years, have come up with a mish-mash of folklore-based tips, tricks and hacks to somehow keep this train running.

Fast-forward a bit, and a lot of these tips and hacks have been refined and codified into the latest revision of HTTP, version 2. The old protocol, the hacks to keep it alive, and now the new version of the protocol, are focused on making the web faster. The problem? Accessing the web accounts for only 14% of the uses of smartphones.

http://www.flurry.com/bid/109749/Apps-Solidify-Leadership-Six-Years-into-the-Mobile-Revolution

And therein lies the disconnect. For almost two decades the web was the dominant application platform. Gigantic hardware and software platforms (and companies) have been built to service the web. (Note how the biggest cloud platform in the world is called “Amazon Web Services”). TCP/HTTP sufficed for web access, but the constraints of what can be done in a web browser have held us back from evolving to the protocols designed for the predominant application of the Internet today: native mobile apps.

Quite simply, for any application running in a web browser, there’s nothing that you, the app developer, can do to fix the underlying network transport. But a new dawn is upon us. The dominant platform for applications is not the web anymore. It’s the native apps on mobile devices. And just like that, we’re free of the shackles of HTTP and even TCP. We, as app developers and our supporters, are free to invent protocols that make sense for this spottily connected, packet-lossy, high-latency mobile world. Evolution, by nature, works at a glacial pace. It’s now time for invention — and maybe even a few quantum leaps. Packetzoom has taken the first step towards fixing these problems by designing a more modern protocol purely for mobile use case. Learn more about it at https://packetzoom.com/learn.html. Here is a short video showing the PacketZoom difference:

About the Author/Chetan Ahuja

Chetan Ahuja is the Founder/CEO/CTO of mobile networking startup Packetzoom Inc. Prior to starting Packetzoom in 2013, Chetan worked on software and networking performance in companies such as Google, Admob and Riverbed where he gained a deep appreciation of the key role of network speed on application performance and thus on user happiness. He holds a Masters degree in computer science from Michigan State University and a Masters degree in computational chemistry from Indian Institute of Technology, Mumbai. He likes to spend the entirety of his free time watching old episodes of Monty Python and Start Trek (TNG) with his family or playing ping-pong with co-workers.

April 6, 2015
Three tips for maximizing efficiency in the age of the hybrid cloud environment
Today’s organizations are achieving many benefits from using virtual computing resources, including increased flexibility, scalability, and accessibility. The adoption of the cloud as an addition to legacy systems has changed the way many companies use IT resources, allowing them to scale quickly and efficiently to meet fast-changing business needs. These hybrid solutions, where companies retain some on-premise functions while moving much of their data and processes to the cloud, are more common than ever. Along with the benefits of using the cloud, however, come significant challenges for the IT organization in terms of managing and monitoring systems.

When pairing legacy infrastructures with cloud computing environments, data center operators and IT organizations run into difficulties when the hardware-based environment (employing older technologies) takes a “bottom up” approach to policies and the cloud environment takes a “top down,” application-centric approach. In this scenario, delivery of services can be interrupted, quality of service can suffer, and utilization rates can drop significantly.

Another challenge comes into play when the same management principles are applied to both physical hardware and virtual machines (VMs), resulting in inefficient sprawl. The phenomenon of “virtual machine sprawl” is a costly but hidden problem; the actual limits of VMs can’t readily be seen, unlike an on-premise site that obviously runs out of physical space. When idle and unused VM sprawl occurs, storage and network resource consumption can easily grow to an excessive level well before it is noticed, at a time when costs are unfortunately too late to rein in.

While virtualization can help shrink costs by the increased density of servers that it provides, a virtual environment can often be pricey too. Cloud resources are indeed finite, and if not managed properly, they can require unexpected increased spending. Users often forget that if they don’t “turn off” or spin down the virtual machine after they are done using it, the machine is still running and resources are needlessly being consumed.

Moving into the cloud environment requires a revised cloud infrastructure plan, one that puts smart management of IT resources squarely at the center of the business strategy. How can you keep business processes moving smoothly, reacting efficiently, and evolving cost effectively in a hybrid cloud environment? Here are three tips:
1. Limit access. Limit the number of people that have access to and the ability to create VMs to reduce the risk of Shadow IT. This simple step channels formal requests regarding VMs to select people with approval powers. With this procedure in place, IT staff must carefully consider if the request is truly needed, rather than hastily completing it with just a few clicks.
2. Allocate wisely. Allocate a designated amount of virtual resources to different departments using resource pools. VM creation is better controlled if you actively limit the resources available per host.
3. Monitor usage. It is vital to closely monitor VM lifecycles to spin usage up and down quickly, which saves money and better utilizes computing resources.
Granted, the manual management of computing resources to accomplish the above tips takes a considerable amount of time. But today there are a variety of sophisticated solutions, such as workload automation, that help create guidelines for both virtual and physical machines. Workload automation allows organizations to take an architectural approach to cloud resource management by building a comprehensive framework that provides greater governance of and control over all of an organization’s virtual and cloud assets. As a result, organizations can better meet SLAs, reduce costs associated with manual management, and greatly increase IT agility.

About the Author/Jim Manias

Jim Manias is Vice President at Advanced Systems Concepts, Inc. and is responsible for the overall market strategy and planning for a range of products including ActiveBatch® Workload Automation and Job Scheduling. Jim has been with Advanced Systems Concepts since 1991 and has held multiple senior management positions in the enterprise software and hardware market. Jim can be reached at JManias@advsyscon.com.
April 3, 2015
One Secure OS for the Cloud – The Rise of Unikernels

In the last few years, a number of open source projects have started to build interesting new technologies to create faster and more secure and scalable cloud applications. The name: unikernels. The goal: develop a new breed of applications (or port existing ones) for the cloud that significantly improve security, performance and scalability by reducing the traditional layer-cake application stack into a single unikernel virtual machine (VM) image. In other words, the operating system, any libraries you need and the application itself are compiled into a small unikernel image.

Traditional application stacks run in parallel within an operating system, which in turn may run in a (VM). The operating system manages resources and isolates applications from one another. In a unikernel, a single application is run in single VM, relying instead on the hypervisor to isolate those VMs. Unikernels are constructed by using “library operating systems,” from which the user selects the minimal set of services required for an application to run. In some unikernels, the compiler and linker eliminate all code that is not used and packages it into a single image that can be directly deployed to the cloud. These sealed, fixed-purpose images run directly on a hypervisor without an intervening guest OS such as Linux.

Unikernels also deliver impressive flexibility, speed and versatility for cross-platform environments, big data analytics and scale-out cloud computing. Like container-based solutions, unikernels fulfill the promise of easy deployment, but also offer an extremely tiny, specialized runtime footprint that is much less vulnerable to attack

A number of unikernel open source projects are beginning to take off, each with its own unique focus and approach. For example, MirageOS and HaLVM take a clean-slate approach and emphasize safety and security; ClickOS stresses speed; while OSv and Rump kernels aim for compatibility with existing applications. Both OSv and Rump kernels have made significant progress in porting existing applications: for example MySQL, PHP and Nginx have been ported to Rump Kernels, whereas many applications such as Tomcat, Jetty, Cassandra, OpenJDK and others have been ported to OSv. Meanwhile, MirageOS has demonstrated 1MB unikernels that serve DNS, Git and SSL web traffic with complete type safety down to the device drivers.

Here’s a closer look at this new, more secure approach for deploying cloud services.

Unikernel Applications Are Easy To Deploy

The basic development and deployment model for unikernel applications is somewhat different than your traditional application stack where an application is delivered as a set of binaries, packages or some sort of installer. Different unikernels take slightly distinct approaches, but in all cases the unikernel application is in effect a VM image, which can directly be deployed into the cloud with zero configuration. This is not all that different from the build once, deploy everywhere model in use by Docker for example.

Let’s look at two unikernels that each have a different workflow.

The typical development workflow for MirageOS is that a developer writes the unikernel application on his local machine (e.g. Mac OSX) and compiles it against a local target. The correct libraries are provisioned through the OPAM package manager and included into the test image. The rationale for not directly developing in a hypervisor is that richer development tools are available locally. After all, a unikernel image is a VM image that contains nothing else but config data and the libraries and services that are used by the application. When the application has been tested, the developer will build a VM image and deploy it into a Xen-based cloud.

Since MirageOS unikernels are so lean, they can even be checked into version-control themselves. This approach has been practiced by the MirageOS community for more than two years and has proven to be extremely flexible and agile. A recent post by Amir Chaudhry on ”Heroku for Unikernels” describes the kind of end-to-end workflows that the team is using.

In the case of OSv, Cloudius Systems developed a tool for rapidly building and running OSv applications called Capstan. “Capstan is as simple and fast as using Docker for creating containers, but the result is a complete VM image that will run on any hypervisor with OSv support,” according to Cloudius Systems.

How Unikernels Deliver Better Security

Security is a key concern as industries move toward networked, scale-out designs with new and varying workloads and data types. Adam Wick, creator of the Haskell Lightweight Virtual Machine (HaLVM) and a research lead at Galois Inc., which counts the U.S. Department of Defense and DARPA as clients, says 2015 is already turning out to be a break-out year for security.

“Cloud computing has been a hot topic for several years now, and we’ve seen a wealth of projects and technologies that take advantage of the flexibility the cloud offers,” said Wick. “At the same time though, we’ve seen record-breaking security breach after record-breaking security breach.”

The creator of MirageOS, Anil Madhavapeddy, says it’s “simply irresponsible to continue to knowingly provision code that is potentially unsafe, and especially so as we head into a year full of promise about smart cities and ubiquitous Internet of Things.”

Galois, which specializes in R&D for new technologies, says enterprises are increasingly interested in the ability to cleanly separate functionality to limit the effect of a breach to just the component affected, rather than infecting the whole system. For next-generation and in-house clouds, unikernels make it possible to run thousands of small VMs per host.

Galois, uses this capability in their CyberChaff project, which uses minimal VMs to improve intrusion detection on sensitive networks, while others have used similar mechanisms to save considerable cost in hardware, electricity, and cooling; all while reducing the attack surface exposed to malicious hackers.

Traditional application stacks running in Linux, and to a lesser degree Docker images, rely on a fairly heavyweight core OS to provide critical services. Thus, a vulnerability in the Linux kernel affects every Linux container, Wick said. In contrast, unikernels follow a an approach similar to a la carte menus: thus only minimal functionality and services needed to run the application are present within a unikernel image. Thus writing an exploit to attack a unikernel application is much more difficult than doing the same for traditional application stacks.

Cloudius Systems, which is running a private beta of OSv, which it tags the operating system for the cloud, recognizes that progress is being made on making container technologies more secure.

“Rocket is indeed an improvement over Docker, but containers aren’t a multi-tenant solution by design,” said CEO Dor Laor. “No matter how many SELinux Linux policies you throw on containers, the attack surface will still span all aspects of the kernel.”

Conclusion

The key takeaway for organizations worried about security is that they should treat their infrastructure in a less monolithic way. Unikernels allow for the careful management of particularly critical portions of an organization’s data and processing needs. While it does take some extra work to build unikernel applications, it’s getting easier every day as more developers address orchestration, logging and monitoring challenges. At the same time, unikernels are no harder to package and deploy than Docker containers. This means unikernels are coming of age just as many developers are getting serious about security as they begin to build scale-out, distributed systems.

About the Author/Lars Kurth

Lars Kurth is the Xen Project Advisory Board Chairman. A Collaborative Project at The Linux Foundation, the Xen Project community is focused on advancing virtualization in a number of different commercial and open source market segments, including server virtualization, Infrastructure as a Services (IaaS), desktop virtualization, security applications, embedded and hardware appliances. Designed from the start for cloud computing, Xen Project members include: Amazon Web Services, AMD, ARM, Cavium, Cisco, Citrix, Google, Intel, NetApp, Oracle, Rackspace, and Verizon Terremark. For more information, please visit XenProject.org.

April 2, 2015
Financial Sector Leading the Way with CD for the database

The financial industry, especially banks, are still using a programming language that is over 50 years old. However, this doesn’t necessarily mean they are out of date, rather these giant institutions have found in some cases that their ancient systems just work. They are stable and secure software programs. But databases are not like static source code; they are always moving and changing. With the most important client information sitting in the database, it’s no surprise that banks and other financial institutions lead all other industries in adoption of Continuous Delivery methodologies for the database.

A recent survey we conducted revealed that the banking and finance industry DBAs far outpace non-financial companies in terms of database Continuous Delivery adoption. Of the 55% of respondents not in the finance space practicing Continuous Delivery, only 49% said they practiced CD on their databases. When we asked banking and finance DBAs and managers, we found that over 70% utilize database automation for software and 64% of those also practiced CD for the database.

These institutions are required to be agile in their database methodologies due to having such a large number of applications to deal with on a daily basis. Moreover, database errors that cause downtime are incredibly costly and financial institutions cannot afford to have any. Aside from the peace of mind that your database can run itself and adapt on the fly, proper database automation and version control can save financial institutions 80%-95% of time it would normally take to manually process changes and there is clear ROI when implementing Continuous Delivery.

The economic effects of unplanned outages are prohibitive. According to a report by Gartner research, unplanned outages, on average, cost $42K per hour. When it comes to financial services companies, research shows the cost are much higher at about $110K per hour, the bigger the footprint that a company has, the more money it will lose when it fails.

These statistics are one of the main reasons that we’re starting to see mainstream adoption of Agile and DevOps practices in finance companies. DevOps favors automating as many processes as possible and automation removes the potential for human error. By automating our processes, we allow machines to handle the redundant tasks freeing up the time and resources of skilled database professionals for more valuable and cost effective responsibilities.

DevOps for Database, automation, control and enforced change management, provide confidence in the integrity and quality of the database code and virtually eliminates the potential that harmful database changes will find their way into production.

About the Author/ Yaniv Yehuda

Yaniv Yehuda, CTO, DBmaestro (http://www.dbmaestro.com/)

Yaniv is the Co-Founder and CTO of DBmaestro, the leading provider of DevOps for Database solutions which enable control of database development and deployment. Yaniv is also the Co-Founder and the head of development for the Extreme group, a leading IT services solutions provider group.

March 24, 2015
A Look into Open Networking Standards
Open source standards hold a lot of potential for networking. Already, initiatives such as OpenStack and OpenDaylight have gained a fair amount of momentum due to the contributions of major vendors such as Intel that recently joining OpenDaylight as a platinum member. That momentum is even spurring telecoms like AT&T to start their own open source efforts like the Open Networking Lab.

Beginning with this entry, I’ll examine various open networking standards and how they are impacting telecom businesses, IT strategy, and network engineering. At a meta level, it’s fair to say that due to the influence of open source development, networking teams are becoming more concerned with APIs, DevOps automation and the need to move away from manual towards automated ways of engineering and operating networks. Of course, each standard brings something different to the table. Let’s look at OpenDaylight.

OpenDaylight: The Open SDN Control Plane Project

The Linux Foundation manages OpenDaylight, the goal of which is to accelerate the development of software-defined networking and network functions virtualization. Though only about two years old, OpenDaylight is already one of the largest open source projects in the world, with 266 developers contributing in the past year or so, and the project already blowing past 1 million lines of code in early 2014.

What does OpenDaylight specifically address? It is perhaps best understood as offering an open control plane solution to enable multiple layers of SDN technologies:
- The data plane layer consists of the physical and virtual devices in the network that speak various protocols northbound to the control layer. This includes but isn’t restricted to OpenFlow.
- Above that is the OpenDaylight controller platform with northbound API’s to the application/orchestration layer, plus a multitude of southbound protocols and APIs exposed to the underlying data plane layer hardware
- At the top is orchestration and application layer. This layer could look like a plug-in for OpenStack Neutron, for example.
OpenDaylight is trying to function as a sort of “Switzerland” of controllers, allowing compatibility with any type of switching hardware via many different protocols and interfaces such as OpenFlow, Path Computation Element Protocol (PCEP), NetConf, etc. The OpenDaylight controller runs on its own Java Virtual Machine and supports the Open Service Gateway Initiative.

Vendors and the future of OpenDaylight

A ton of networking vendors have piled onto OpenDaylight, to such an extent that detractors are arguing that the project, despite its open source moniker, may end up actually preserving the position of networking incumbents. Cisco and IBM founded OpenDaylight and were followed as members by Brocade, Juniper, Microsoft, Intel and others. A huge portion of OpenDaylight’s code contributions are made by large networking vendors.

With OpenDaylight in particular, the contributions of Cisco have often been scrutinized due to Cisco’s unique take on SDN and what type of controller should be used. Network World’s Jim Duffy has previously referred to Cisco OpFlex as an “OpenFlow killer”, which may be an exaggeration, but it’s clear that Cisco has something other than OpenFlow in mind for the future of OpenDaylight’s core. OpFlex could be a key part of the Lithium release that will succeed OpenDaylight Helium. However, Guru Parulkar, director of the Open Networking Lab, cited OpFlex’s exposure of device specifics to applications as a needless complication and one of the reasons for creating an alternative to OpenDaylight.

Of course, it’s a difficult balance for vendors to achieve between innovating in their own product and service lines and participating in the open source community. Projects like OpenDaylight demonstrate the promise of open source software in enabling SDN orchestration, the “wild west” nature of openness and the risks of having incumbent vendors become the de facto new sheriffs in that wild west landscape due to sheer muscle. A middle path is clearly needed.

“The vendor’s role in open-source networking projects should be a symbiotic one with other members of the community,” wrote Mike Cohen for TechCrunch. “This includes contributing to open-source efforts for the good of the community while continuing to innovate and build differentiated products that better meet user needs. Vendors should also contribute some of those innovations back to the community to help promote new standards that will help the market continue to grow.”

The upshot: OpenDaylight, initiated by Cisco and IBM in 2013 and now hosted by the Linux Foundation, is not only a significant open networking standard but one of the most prominent open source software movements period. It defines an open controller with a wide set of southbound protocols APIs for different types of infrastructure and northbound integrations. The shape that vendor contributions to and relationships with OpenDaylight take will be critical both to its rapid progress in delivering features, but also to its future as an inclusive effort at improving SDN and NFV orchestration and network DevOps.

About the Author/Alex Henthorn-Iwane

Alex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing and product management at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.

Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing, software defined networking and network function virtualization, DevOps, ITaaS, and IT automation and orchestration. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.

These days, Alex focuses a lot of his writing around the intersection of new, programmable infrastructure technologies (cloud, SDx, NFV), DevOps and the orchestration and automation enablement needed to make all of them a reality, in both the enterprise and service provider/carrier space.

Connect with him on LinkedIn | Twitter | SlideShare
March 20, 2015
In DevOps, On-Prem Is Dead

What you need to know about SaaS management tools

The SaaS vs. on-premise debate has spanned the years since new age consumption models for technology were born.

The accepted reasons to adopt SaaS are no-brainers for DevOps organizations. SaaS lets you start up fast, is asset-free, and has a lower commitment subscription model. You expect time to production in hours or days, rather than the months or years that an on-premise software installation can take to fully deploy the solution. Here’s why SaaS IT Ops tools are a better choice for your DevOps implementations:

Agility and Time to Market. It makes no sense to invest up-front in a solution that commits you to a technology when you’re moving at light speed. Long feature release cycles from traditional software vendors and the regular maintenance required slow down your DevOps teams. On-premise upgrades will likely require central IT support, not to mention the risk inherent in upgrading the software.

Evergreen Platform. As you grow your environment and add new technologies, your management solution needs the requisite features and plugins to work. A SaaS platform continually updates the technology, behind the scenes at the vendor, so your engineer’s time isn’t wasted on managing the maintenance and upgrades.

Microservices. With application workloads migrating to the cloud, monolithic app architectures are falling out of favor. Microservices allow you to build applications as suites of services where each unit of software can be independently upgraded. Enterprises can quickly adopt hybrid cloud architectures thanks to microservices, where some services live in a public cloud while others in owned data centers. SaaS tools offer an integrated approach to monitor dynamic architectures by tracking the performance of your application as a logical entity before and after each update.

Infrastructure as Code. With Infrastructure as code, sysadmins use automation frameworks for standing up or turning off production environments. IT teams can orchestrate complex deployments without manual intervention in an error-free manner. SaaS tools help you manage automated infrastructure that’s written as code and monitor different production instances across hybrid clouds.

Enterprise applications are clearly going the SaaS way. By 2018, IDC estimates that 28% of enterprise software will be SaaS based with on-premise software attaining negative growth rates. Embrace the age of agile operations by leveraging SaaS tools to improve build quality, increase release velocity, and manage complex infrastructures across your enterprise.

About the Author / Varma Kunaparaju

Varma Kunaparaju is CTO at Vistara and a seasoned technologist with over 20 years of experience leading engineering teams to deliver enterprise software. Reach him on twitter at: @varma1

March 18, 2015
Dev and Ops Coming Together To Combat the Weakest Security Link – BYOD
Traditionally, security threats have taken the form of intentional acts by remote attackers: somebody on the outside working covertly to get to the inside. This is the classic scenario that most people associate with IT security, and it’s what most network operators are best prepared for. But these classic threats are eroding rapidly in the era of ubiquitous mobile devices and users who’ve become accustomed to always-on network access. BYOD is the weakest security link today.

The surge in mobile wireless devices has blurred the line between what is inside and outside the network. Mobile devices such as smartphones and tablets are legitimate, and increasingly indispensable, business tools. Immersed in social media and digital technology, many Millennials treat their mobile devices as extensions of themselves, making it very difficult to separate one from the other. The obvious cost of a policy that prevents users from bringing personal devices to work is impacting the recruitment of new staff, and sometimes depriving existing staff of the tools they need to stay competitive, but the risks are also substantial.

The Technical User

While many fear the untrained user, the worst threats may come from the technically literate user, such as a developer or engineer, who feels he or she simply cannot work without their mobile device and unfettered access to the network. Such a user may not take no for an answer when it comes to bringing in their mobile device, and may even go so far as to employ their own personal hotspot hardware or software to bridge the gap between the protected work network and their unauthorized devices.

No ill will is intended by this act; the user simply thinks s/he knows better. S/he wants to be able to use the devices that make work life easier and knows how to set up an access point to do just that. They don’t realize or just ignore the fact that an access point outside the purview of IT security or ops poses a significant risk to the network as a whole. Without being able to verify the integrity of the hotspot or its configuration, ops can’t be sure if it’s being held to the same security standards as the rest of the network.

While these technical users know how to bypass the system, they may not know how they are leaving their network open and vulnerable. A developer with access to sensitive information, perhaps even branches of source code, may be restricted by the security team from accessing certain portions of the Internet while on the developer network. A technically adept but perhaps not security-conscious developer could attempt to bypass these restrictions by setting up an access point of his or her own – though this may give him or her access, it also gives attackers access to his or her machine. Developers have sensitive information on their laptops that needs to be protected, and connecting to unsecure networks can put this IP at risk. A developer bridging the network using a 4G adapter or access point not only exposes the information on his or her laptop; it also creates a hole that could expose the entire network to infection. Being alerted to these access points is an important step in validating your security controls.

Best Practices: Finding a Balance

The most important steps for creating and implementing a security policy that works both from a security and an efficiency perspective are elaborated below: assess your developers’ needs, set reasonable controls, and validate those controls. Together, they represent a balanced approach to addressing the often conflicting needs of an organization.
1. Assess Your Developers’ Needs
Preventing developers and technical users from connecting devices to the network, or placing overly restrictive limits on their devices, can inadvertently lead to more security issues than otherwise. With overly restrictive policies, users are more likely to take matters into their own hands and bypass security controls. The best course of action is to engage these users to determine what their work motivations are, and meet them as closely as the overall security and operation of the network will allow. Ideally make the users allies to ops, not adversaries. These developers are knowledge workers, often well compensated, with some degree of entitlement, and cultivating an environment of trust and cooperation is in the best interests of all involved.
1. Set Robust – But Reasonable – Security Controls
This may be stating the obvious, but the most important part of empowering your developers is to mutually set expectations. Properly established security controls are really just agreed-to expectations, laid out in a manner that allows developers to understand what is expected of them and how to appropriately bring up concerns or exceptions. These expectations should be both reasonable and attainable. The most important part of adopting a “bring your own device” (BYOD) policy is to adopt one that meets the needs of the developers while maintaining security and validation. An inappropriately onerous process will encourage users to bypass the process, leading back to an insecure environment with gaping holes in network security. There is a range of tools to consider that can support controls. For example deciding if managed device management (MDM) tools are to be used or not is a major consideration that will drive controls and network access.
1. Validate Controls with Visibility
Security controls are frequently talked about, but less often mentioned is the validation side of the process. You can establish as many controls as you feel necessary, but without visibility into the network, controls are more words than reality. While seeing access points is important to evaluating the risk at your offices, it is only half the battle. The most important thing is finding devices operating on the access point and understanding what access they have to the internal network. With a list of which devices have been attached to the access point in question, it’s a simple process to identify where an offending device is located, and who is responsible for its existence.

Once you’ve found the rogue access point and its operator, it’s time to perform triage. Was the access point connected directly to the business network, or did it get Internet connectivity over the cellular network? If it was on the business network, what kind of access did it have? Was it behind a firewall, or did it expose critical network components such as servers to the outside?

These types of questions will help steer the subsequent investigation and save valuable time. It may end up that the access point posed no direct threat to the business network itself; such as the case of a personal hotspot tied to a cellular modem. In that sort of best-case scenario, the network operations team may simply need to reinforce the rules and regulations of the network, and explain the importance of keeping the network isolated from the outside world.

What Does a Rogue Access Point Make Vulnerable?

While these rising risks have grown with the erosion of classic IT boundaries, your information is still both valuable and vulnerable. Data and Intellectual Property are two of an organization’s most valuable assets; without good security processes, quick development cycles are futile.

About the Author/Paul Paget

Paul Paget is the Chief Executive Officer of Pwnie Express, provider of end-to-end security assessment solutions. He brings more than 30 years of of leadership experience in technology companies and information security to the company. Follow Paul on Twitter: @pgp2
March 16, 2015
A Three Step Roadmap for Enterprise DevOps
The extremes of application release velocity are converging in the enterprise. Whereas Fortune 500 enterprises may have historically taken months to years for each release cycle, they are exploring new approaches from new age Internet technology firms that release new versions of an application several times in a day.

According to a recent report on DevOps adoption, 86% of IT and business decision makers have either implemented DevOps or will roll out DevOps initiatives within the next 3 years. There is a strong appetite for enterprise DevOps, but where do you start?

For DevOps projects, Ops will need to shift from a systems management approach to a programmatic approach. Ops should work with Dev to figure out the automation required to provision and deploy the application. Here is a three step roadmap for enterprise DevOps for those organizations looking to roll out successful DevOps initiatives:

Step 1: Select The Right Application Candidates.

Not every enterprise application is a right candidate for DevOps. Traditional applications are not architected for DevOps velocity, whereas enterprise applications designed with agile and iterative techniques are excellent candidates for DevOps. DevOps may be an overkill for applications where the underlying business process rarely changes. Dev and IT Ops should choose one or two applications for DevOps style implementation.

Step 2: Manage Your Application Lifecycle With Automation.

Provision applications as part of the build process itself. During deployment, Ops should be able to execute a piece of code to identify application monitoring needs. Your automation framework should manage application health without manual intervention.
- Can you fix application issues using runbooks?
- Do you have scripts for scaling, maintaining, and load balancing the application?
- How do you plan for new releases?
- How do you upgrade the application?
Treat your infrastructure as code. Application configuration, deployment, and maintenance all need to be part of an automation framework. Ops should build concurrency with the application. You should be able to configure, deploy, and bring the entire application live within no time.

Step 3: Embrace Compliance Driven Operations.

Your IT Ops automation framework should deliver the right visibility to support more frequent releases without complex manual processes.
- Are you able to automate monitoring of the infrastructure for delivering the best end user experience?
- How do you ensure that the right infrastructure resources are available for running the application?
- Can you keep your infrastructure current by maintaining the right patch levels?
Enterprises can modernize application delivery pipelines by selecting the right application candidates, managing application lifecycles with automation, and embracing compliance driven operations. While you might never deploy code 23,000 times a day like Amazon.com, the Enterprise DevOps framework will help you release applications faster, with higher quality and lesser risk of deployment failure.

About the Author / Varma Kunaparaju

Varma Kunaparaju is CTO at Vistara and a seasoned technologist with over 20 years of experience leading engineering teams to deliver enterprise software. Reach him on twitter at: @varma1
March 13, 2015
Building software quality into your Continuous Delivery pipeline

The modern software development landscape places a premium on speed. It’s good to be first to market. If you’re going to fail then you should fail fast. A rapidly evolving product can be shaped according to customer feedback, and fast turnaround allows you to stamp out defects and hone the software for your audience.

A continuous delivery pipeline enables you to act and deliver more quickly. But you need to build in quality metrics to ensure it retains a laser focus, and doesn’t become an out-of-control fire hose. It may require some front-loaded effort and resources to set an accurate measure, but the resultant software quality turns short term cost into long term savings.

Plan for quality

You can build the expectation of quality into your software development process from the start. Design your tests before a line of code is written. Create a test architecture that can be woven into your CD pipeline. Build a self-adjusting system that applies the right tests at the appropriate time in development, covering unit tests through to performance testing. That way you always have the real-time insight you need into your software quality.

Why wait?

Test-driven development can save time and resources. By waiting for functionality to be developed before writing up your automated functional tests you’re creating more steps to complete than is necessary, and slowing down the process.

You need real examples of each feature and piece of functionality in order to design and implement it anyway, so why not create them from the beginning? They can serve as acceptance tests and keep developers focused on the core requirements for your software.

This can only work if you ensure that you have group buy-in from day one. All stakeholders must be involved in the acceptance test design. If you fail to get the input you need about what constitutes a holistic view of your software quality, then you can expect feedback that raises new concerns down the line. By that time it will be more difficult and expensive to retro-fit new quality metrics.

Aim for automation

The more of your acceptance criteria you can automate, the better. It provides you with a mechanism for taking the temperature of your software whenever you want to, for a clear picture of its health.

Naturally, there will be acceptance tests that you can’t automate. You shouldn’t try to automate everything. There’s no substitute for human insight and it’s notoriously difficult to predict your end user’s first impressions.

Functional tests are ideal candidates for automation, provided your test architecture considers optimization for regression and remains flexible enough to accommodate new examples when required. For the most efficient use of your resources you need to build in an understanding of dependencies. You need control over the decision on what to test and when, based on the quality attributes you’re examining.

Failures will be flagged at the earliest eventuality for all stakeholders, maximizing your opportunity to address them quickly. By building these quality metrics into your CD pipeline you can go live with confidence.

About the Author/Viktor Clerc

Viktor Clerc is product manager for testing applications at XebiaLabs, a provider of automation software for DevOps and Continuous Delivery helping companies to accelerate the delivery of new software. You may reach him at vclerc@xebia.com.

March 4, 2015