Containers are more secure than apps running on a bare OS and organisations that like not being hacked therefore need to seriously consider a move, according to analyst firm Gartner.

Analyst Jeorg Fritsch, in a new document titled How to Secure Docker Containers in Operation says “Gartner asserts that applications deployed in containers are more secure than applications deployed on the bare OS” because even if a container is cracked “they greatly limit the damage of a successful compromise because applications and users are isolated on a per-container basis so that they cannot compromise other containers or the host OS”.

Which is not to say that containers are perfect: the paper acknowledges that they possess “… innate security properties that make them vulnerable to kernel privilege escalation attacks” and are therefore “not the right tool for high-risk-assurance isolation.”

The paper nonetheless advocates that organisations “Benefit from the security of Linux containers by using a ‘container €first’ approach” and “Deploy internet-exposed applications in Docker containers with best-practice security whether or not you do CI/CD/DevOps.”

Which is not to say containers are a magic security fix. As the paper’s name implies, Docker needs to be done right in order to deliver its security benefits. Doing it right means hardening the host on which Docker runs in accordance with Docker’s own guidance, then considering third-party Docker security products from the likes of Aqua Security, CloudPassage, Twistlock and Weave. Mastering logical security zoning and network isolation is a must. You’ll also need to wrap your head around microservices routing, so that when you start to build apps comprised of containers chatting to each other they do so securely.

You’ll also need to understand kernel controls to ensure your containers get the right level of access to their host’s kernel.

“In the Linux OS and in Linux containers, every system call is a direct interaction with the kernel,” Fritsch writes, noting that’s “the very same kernel that all segregation features depend on. System calls are a signi€cant attack surface, where nothing must go wrong.”

Overall, however, the paper suggests that organisations consider a move to containers. And not just to keep up with the DevOps crowd. ®

Sponsored:
Global DDoS threat landscape report

Linux and Chromebook users now have new versions of Skype to play with.

Microsoft launched an alpha version of a new client for Linux on Wednesday, in a push to get users of the open-source operating system to make video calls and send messages with Skype.

There was a Linux client available for the service previously, but this launch is a move by the company to get users of the operating system on the latest version of Skype. Users will get a new interface, emoticons, and a file-sharing interface.

Chrome users will be able to use web.skype.com to make calls from Google’s web browser and desktop operating system starting Wednesday, too. Like the Linux client, the new Chrome client is still in alpha, so there are likely to be bugs, along with missing features.  

These launches are important as Skype faces increased competition in the messaging and digital calling space. Apps like Slack, WhatsApp, Facebook Messenger, and Google Hangouts have all either built or are building voice and video calling functionality into their services. 

The new Linux app allows users to connect with other people using the latest versions of Skype across many other platforms. But it’s based on new calling architecture that makes it incompatible with the previous version of Skype for Linux and some older versions of Skype on other platforms. 

Microsoft’s supersize Surface Hub is often viewed as a computer for videoconferencing and digital whiteboarding, but it is emerging as more than just the centerpiece of a conference room.

The Surface Hub is a one-of-a-kind, all-in-one PC with a 55- or 84-inch screen that started shipping a few months back. The device provides new ways for users to present, exchange, share and manipulate data from the Azure cloud, said Hayete Gallot, general manager at Microsoft Devices.

Users are still exploring ways in which it can be used. The large screen and collaborative features can be powerful tools in visualizing data extracted from the cloud, Gallot suggests.

Microsoft and SoftBank Robotics are linking Surface Hub panels to the Azure cloud services platform to make shopping easier for shoppers in stores. The Surface Hub will make purchase recommendations based on an analysis of data collected from stores, customers, point-of-sale purchases, smartphones, e-commerce sites and other sources.

For businesses, Azure can turn cloud-based data into presentations on the Hub. The inking and touch features allows business users to take take the data, create different models, make comparisons, and then make projections, Gallot said.

There are many examples of ways in which the Surface Hub could tap into Azure for business planning, forecasting and customer engagement, Gallot said.

The ability to use a large-screen computer to manipulate and present data is highly valued in sectors like finance, where critical decisions are made based on big-data insights, Gallot said.

Hospitals are replacing whiteboards with the Surface Hub, which uses Skype for Business for videoconferencing and OneNote as a digital whiteboard. Applications hosted on Azure are also now being used on Surface Hub.

Mural, a cloud-based digital whiteboard hosted on Azure, is being used on Surface Hub so remote workers can collaborate on documents and product designs. The service can be fired up during Skype videoconferencing sessions.

Azure itself is also closely linked to other hardware. HP considers Azure a key element in the ability to convert its Elite X3 smartphone into a PC alternative. Azure also provides the middleware for makers using Raspberry Pi 3 to connect internet of thing devices and cloud-based services, said Eben Upton, founder of Raspberry Pi, in an interview.

Starting at $8,999, the Surface Hub isn’t for everyone. It won’t be upgraded as often as regular tablets and PCs, but it’s versatile and the use cases will continue to expand, Gallot said.

The Automotive Grade Linux (AGL) project is about to unleash the second version of its unified code base – snappily called UCB 2.0 – with expanded hardware support and

For the participating car-makers and hardware vendors it’s a big deal.

Features landing in the latest distribution include support for a rear seat display with video playback, letting a rear-seat passenger control video from their touch screen; audio routing supporting both GENIVI (“IVI” stands for in-vehicle infotainment) and Samsung’s Tizen. There’s also a new build environment and a new test infrastructure.

What will be exciting the project most, we suspect, is that this version supports a lot more hardware than AGL supported in January 2016.

Back then, there were two Renesas boards and a QEMU x86 virtual machine with AGL; now, the distribution supports hardware from NXP, Qualcomm’s DragonBoard, TI’s Vayu EVM, the Raspberry Pi, and various Intel boards.

The project reckons its vehicle messaging bus will block car hackers, by preventing rogue applications from talking to the vehicle bus; and the application framework similarly has an eye to security, with resources assigned only to approved applications.

The distribution will get its download button during the Automotive Grade Linux Summit in Tokyo this week. ®

Sponsored:
Accelerated Computing and the Democratization of Supercomputing

Microsoft has released details of how Windows Server 2016 will be released and maintained, and as with Windows 10 it includes a “Windows as a service” model of frequent operating system updates.

Windows Server 2016 will be launched at the company’s Ignite conference, which runs from September 26 to 30 in Atlanta, Georgia. As with the current release, there will be three editions: Datacenter, Standard and Essentials.

Several things are new, though. One is that Windows Server 2016 will be priced and licensed per core, rather than per physical processor.

Another is that the Datacenter and Standard editions have a new installation option called Nano Server, which is a stripped-down version designed for lightweight virtual machines, or a low-overhead host for virtual machines. Nano Server has no GUI and can only be managed remotely.

There are also changes to the way Windows Server is serviced. Datacenter and Standard can be installed either as Long-Term Servicing Branch (LTSB) – with five years of mainstream support and five years of extended support – or as Current Branch for Business (CBB), in which case you can expect feature updates two or three times a year. These terms are familiar from Microsoft’s Windows 10 release, which follows a similar pattern.

When it comes to a Nano Server installation though, Microsoft is only offering CBB. You will have to upgrade regularly to a release with new features, or it will not be supported.

“Only two CBB releases will be serviced at any given time, therefore when the third Nano Server release comes out, you will need to move off of #1 as it will no longer be serviced. When #4 comes out, you will need to move off of #2, and so on,” explains the team in a blog post.

A further twist is that because Nano Server is CBB only, Microsoft is disallowing its use in production unless you have Software Assurance, an enhanced (and more expensive) license which permits version upgrades.

Microsoft’s licensing guide also shows that use of Windows Server Containers, a key new feature, is limited to two instances with the Standard Edition if you use the better-isolated Hyper-V containers. Non Hyper-V containers are unlimited with either edition.

Features reserved for the Datacenter edition include Storage Spaces Direct, Storage Replica, software defined networking stack, and shielded virtual machines.

The per-core pricing for Windows Server 2016 requires a minimum of eight 2‑core licenses for each physical server. In its licensing guide, Microsoft states that “the price of 16‑core licenses of Windows Server 2016 Datacenter and Standard Editions will be the same price as the 2‑processor license of the corresponding editions of the Windows Server 2012‑R2 version.”

One piece of good news though: there will still be a free Hyper-V Server Edition if all you need is the hypervisor. ®

Sponsored:
The Nuts and Bolts of Ransomware in 2016

Two decades ago, the core was the place to be in campus networking. The networking battles of the 1990s concluded with the edge specialists humbled and assimilated by core product lines. Control the core, we declared, and the edge will fall into place.

But now the edge is fruitful, and the core is sterile—and for two reasons. First, the wireless interface adds mobility and complexity to the edge. Second, the new architectures of software-defined networking (SDN) and IoT are based on centralized models that take sensed information, manipulate a software representation of the network, then send control signals back to network nodes. Nodes are peers under the controller. Their importance is based on the quantity and quality of the information they can report, as well as the sophistication of the control they can apply.

Wired edge switches, on the other hand, have relatively simple functionality. Wi-Fi access requires a network edge with 802.1X authentication, dynamic VLAN assignment and mobility constructs. These are all sophisticated architectures, and they account for the emergence of specialist WLAN overlay equipment. The last decade showed traditional Ethernet switch designers were unable to build state-of-the-art Wi-Fi hardware and software into their products, although they were well-positioned in the market.

The power of the Wi-Fi network edge

However, it is the new thinking around SDN that makes the Wi-Fi network edge especially powerful. Its centralized, abstracted network model must be fed with the current state of the network. Where can it get the most information on network state?  From the edge.

Access points sense the RF signals from connected devices, identifying location and tracking mobility. They are involved in authentication, learning the identity and status of devices. They monitor ARP, DHCP, mDNS, DNS and other protocols, providing insights into connectivity requirements. And they are in the data path, able to profile and report traffic flows. No other network node is placed to monitor all these protocols. The farther one travels from the edge towards the core, the more information is lost.

Thus far, SDN implementations have dealt mostly with optimum routing through the network, treating the access point like a wired edge switch—although there have already been various research projects seeking to extend the model. But as SDN technology matures, it will place more emphasis on the wireless network edge to report complete information on client devices and traffic flows to the central controller.

And in the opposite direction, the controller will apply policy to its model of the network, its traffic and device requirements, sending control signals to reconfigure the physical network. To which network nodes will these signals be directed? Surely, to the edge. This is where authentication can be interrupted, addresses dynamically assigned, ARP and other multicast protocols passed or blocked to create connectivity maps and quality of service, and data traffic interdicted, diverted or modified for appropriate levels of user experience.

Interfaces are important in our universe. The biosphere, software APIs, human skin, (some even consider the white cliffs of Dover a significant interface)—the list is long, and we can now add another, the wireless network edge. Wireless access points have not yet received the attention they deserve in architectural discussions, but they are set to become the principal sensor and policy-enforcement points of the campus network, continuing the resurgence of the edge.

This article is published as part of the IDG Contributor Network. Want to Join?

Comment Rolls-Royce and the Advanced Autonomous Waterborne Applications Initiative (AAWA) believe the future of cargo transportation is autonomous – and they have published an 88 page white paper (PDF) to prove it.

The company outlined its vision of remote controlled cargo ships at the Autonomous Ship Technology Symposium in Amsterdam last week, claiming unmanned vessels would be cheaper to operate and would have more space for cargo.

Speaking at the Symposium Oskar Levander, Rolls-Royce, Vice President of Innovation – Marine, said: “This is happening. It’s not if, it’s when. The technologies needed to make remote and autonomous ships a reality exist.”

He continued: “The AAWA project is testing sensor arrays in a range of operating and climatic conditions in Finland and has created a simulated autonomous ship control system which allows the behaviour of the complete communication system to be explored and we will see a remote controlled ship in commercial use by the end of the decade.”

The project also has the support of ship owners and operators. The tests of sensor arrays are being carried out aboard Finferries’ 65-metre double ended ferry, the Stella, which operates between Korpo and Houtskär, while ESL Shipping Ltd is helping explore the implications of remote and autonomous ships for the short sea cargo sector.

If introduced in this timeframe, ships could beat cars to be the first autonomous vehicle to be rolled out on a significant scale.

The route to transform commercial shipping is not plain sailing, however, with the white paper warning that autonomous ships may be more vulnerable to piracy as inadequate security would potentially mean hackers could commandeer the freighters.

“In principle, anybody skilful and capable to attain access into the ICT system could take control of the ship and change its operation according to hackers’ objectives,” the white paper states.

“This could mean simply some disruptive actions or manoeuvres introduced for annoyance or demonstration, hijacking of the ship and cargo for ransom, but also powered groundings or collisions created on purpose to cause severe destruction.”

Rolls-Royce is not first to float the idea of autonomous ships, with the US Navy launching its first fully autonomous warship, dubbed the Sea Hunter, earlier this year in what is seen as a dramatic advancement as we head towards fully autonomous, hunter-killer weapons platforms – but unlike its USN counterpart, Rolls-Royce still plans for there to be a human in the loop – albeit someone in a control center thousands of miles away. ®

_{This column was originally published on The Futurist.}

Sponsored:
The Nuts and Bolts of Ransomware in 2016

Today, we are pleased to announce that the HDInsight tool in Azure Toolkit for Eclipse is generally available. Since our GA announcement of HDInsight Tool for IntelliJ, we are maintaining our strong momentum to serve the open source community and expanding our support for Eclipse. The HDInsight Tool for Eclipse is part of the Azure Toolkit for Eclipse and will be of particular interest to HDInsight Spark developers. It is an open source project as part of Azure Toolkit for Eclipse, whose source code is available under the MIT License from the project’s site at: http://bit.ly/29l1YnJ.

The HDInsight Tool for Eclipse is intended to improve usability, boost productivity of Spark developers and enable you to enjoy native Scala and Java development experiences from Eclipse. For big data developers building Spark applications on HDInsight, it can sometimes be hard to get started building your first application, and the Spark application development lifecycle in IDE can be long and tedious. With this tool, you can get started with HDInsight Spark in just a few minutes and experienced Spark developers can iterate their development cycles faster and easier.

What features are supported in HDInsight Tool for Eclipse?

The HDInsight Tool for Eclipse extends Eclipse to allow you to create and develop HDInsight Spark applications and easily submit Spark jobs to Microsoft Azure HDInsight Spark clusters using the Eclipse development environment. It integrates seamlessly with Azure, enabling you to easily navigate HDInsight Spark clusters and to view associated Azure storage accounts. To further boost productivity, the HDInsight Tool for Eclipse also offers the capability to view Spark job history and display detailed job logs. 

The HDInsight Tool for Eclipse offers the following key capabilities:

•    Create Spark projects with built-in templates, sample code and intelligence to autocreate artifacts and locate assemblies. 
•    Develop Spark applications with native authoring support (e.g. IntelliSense, auto format, error checking, etc.) from Eclipse (mainly Scala and Java).
•    Submit Spark applications to HDInsight clusters.
•    Allow users to stop a running Spark application before its completion.
•    Test and validate Spark applications locally.
•    View all the Spark clusters associated with a user’s Azure subscriptions.
•    Navigate the associated storage resources of a user’s HDInsight Spark cluster.
•    Cache the Spark logs to disk in case the Spark logs are too big.

How do I get started?

You need to first install Eclipse and download the prerequisite files including Java SDK, Scala IDE for Eclipse and Microsoft HDInsight Spark Cluster, then get the latest bits by going to the Eclipse repository and searching “Azure Toolkit for Java”. Eclipse will also prompt you for the latest updates if you have previously installed the Azure Toolkit for Java plugin.

For more information, check out the following links:

•    Video: Introducing HDInsight Tools for Eclipse for HDInsight Spark Development
•    Documentation: http://bit.ly/29xQ11T

Learn more about today’s announcements on the Azure Data Lake Blog.

Discover more Azure service updates.

If you have questions, feedback, comments, or bug reports, please use the comments below or send a note to [email protected].

Here’s the dirty little secret about the Internet of Things: The Things might not work, and you might not use them.

As a consumer, many of your gadgets will collect dust tucked away in a drawer (I must admit, I have a large box full of wearables and other things with which I don’t know what to do). As a business, many of your devices will not perform as well as expected, turning into maintenance-heavy money pits.

This is because it’s hard to gauge the usefulness of a new, innovative hardware Thing. Some won’t be useful; others will stop working. Even the ones that you love, the hard-working devices that serve you every day, will soon become obsolete, replaced by newer, better, shinier Things.

And so we keep buying these new Things, seduced by their promises — and later often find ourselves saddled with buyer’s remorse.

But soon, thanks to a concept called Hardware–as–a–Service (HaaS), we’ll have fewer of these regrets, because we’ll own fewer of these Things. Thanks to HaaS, the way individuals and businesses consume hardware products is changing.

What is Hardware–as–a–Service?

Hardware–as–a–Service, which clearly has roots in Software-as–a–Service, is a business model where companies sell packages that include hardware, software, maintenance and, sometimes, installation, for a monthly fee. Under HaaS, customers pay for services, not Things; consequently, HaaS contracts often include a service-level agreement (SLA).

Here are some examples:

Vivint is a smart-home company that offers security sensors, smart locks, thermostats, installation, servicing and 24/7 customer support for a monthly fee. Most of this hardware is made by the company. Plans start at around $60/month, with a free trial period and minimum contract length. With more than 1 million customers and $650 million in revenue, their strategy seems to be working.

Hitachi recently announced a “trains as a service” contract with Virgin in the U.K. for 65 new high-speed Hitachi trains. Under that deal, Hitachi maintains ownership of the trains, and is paid based on their trains’ reliability.

In fact, transportation is the leading edge of HaaS. Bike-sharing programs like NYC’s Citi Bike provide access to bicycles for as little as $15/month. In many cities, car-sharing programs like Zipcar and car2go have replaced the need to own a car. Uber recently launched $5 rates to provide an everyday transportation option for commuters, further reducing car ownership needs.

Even the large tech companies are starting to get on board. Earlier this month, Microsoft launched “Surfaces-as–a–Service,” allowing business customers to pay a monthly fee for a Microsoft Surface, unlimited phone/in-store support and hardware upgrades. HP is reportedly exploring HaaS plans for their device product lines. And some analysts believe that an “Apple-as–a–Service” subscription-based revenue model is the answer to that company’s woes.

The advantages of HaaS

Hardware–as–a–Service is here because it makes sense. Almost all hardware is a depreciating asset: why would we want to own it? For example, a new car loses nearly 10 percent of its value when driven off the lot. In these cases, it makes simple economic sense not to own.

HaaS also taps into the current zeitgeist of minimalism, where books about decluttering become bestsellers and less-than-400-square-foot houses become the focus of popular TV shows, as well as the growing sharing economy.

There are many more advantages for customers. HaaS transforms an up-front capital expenditure into an ongoing operating expense, which also allows for more accurate cost/value comparisons: e.g. “Is this worth $X/month to me?” Operating expenses become cheaper through shared use, especially for Things we don’t always use: e.g. bike/car sharing.

There is less worry about maintenance because of bundled-in servicing, which means any errors, bugs and other misbehaving gremlins become the headache of the hardware provider. Included servicing also caps the total cost of ownership: You know exactly how much it will cost for as long as you use it.

With HaaS, problems are fixed faster: Sometimes the hardware provider is not paid if the Thing is not operating (e.g. Hitachi’s trains), which incentivizes them to repair equipment quickly, even proactively (i.e. preventative maintenance). And there is less need to worry about obsolescence. You pay for the service, not the hardware; newer, cheaper hardware often enables the provider to offer a better service to you, which encourages them to upgrade.

HaaS also has advantages for IoT companies, just as software vendors benefited from SaaS. HaaS is easier to sell because of the lowered up-front cost. HaaS contracts generate predictable monthly revenue. HaaS plans create longer customer relationships, which can drive further sales. Bundling hardware, software, maintenance and installation improves margins: Pricing becomes a function of the value provided, not of the underlying (and diminishing) hardware costs. In other words, HaaS can be a shield against the endless march of hardware commoditization.

What is old is new again

Of course, HaaS is not completely new — we’ve already seen a similar transformation with SaaS, which paved the way by making subscription services widespread and generally accepted. HaaS is also a result of the recent flood of innovation released by the lowered barriers for building hardware: cheaper components, easier prototyping, more accessible contract manufacturers, newer distribution channels and hardware-friendly investors.

It is the next step in the evolution of product-delivery models: from buying, to financing, to renting/leasing and now to HaaS.

The key difference with HaaS is you pay for the usage of the service, not the asset, which is why we see HaaS under a variety of names: Smart-Home-as–a–Service (Vivint), Trains-as–a–Service (Hitachi), Cars-as–a–Service (Zipcar, car2go, Uber), etc.

In other words, HaaS is a new way of thinking. HaaS changes the relationship between the vendor and customer, extending a one-time transaction into a long-term relationship. This means customers need to pay more attention to how their vendors operate, and vendors need to pay more attention to their existing customers.

Of course, HaaS may not fit all hardware products. Some devices will be so cheap that they’re disposable. Some will be so expensive that they’ll require up-front payment just to support cash flow needs (especially for startups). Other businesses will still thrive off of crowdfunded pre-sales.

But HaaS is here, and we are better off because of it.

Thanks to Mike Freedman, Jamie Cuffe and Nitin Chopra for reading drafts of this article.

Featured Image: Alonso Aguilar/Shutterstock

DevOps is a concept that we’ve all started coming across more and more in the last few months. Critically it’s taken a bit of a leap just lately because people have started to: (a) define it formally and (b) actually agree to a decent extent on what the definition is.

So, for what its worth, Wikipedia talks of DevOps as: “A culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.”

Webopedia, for its part, calls DevOps: “A type of agile relationship between Development and IT Operations” whose aim is “to change and improve the relationship by advocating better communication and collaboration between the two business units”.

Okay, all well and good. But is it actually a proper thing or is it just a relatively young term that people throw about without either understanding it or meaning it?

Well, first of all I’ll start by saying that I don’t really like the second half of Wikipedia’s definition: I fail to see what specific relationship DevOps has with automation. I do, however, get a warm feeling from the fact that both these definitions (which happened to be the first two I picked at random) both include the words communication and collaboration. So perhaps there’s something in the concept.

Over the last few years I’ve worked in both halves of the DevOps definition, so I’m fortunate in having seen first hand what problems exist between the development world and the operational world. So the operations guys eye the developers with an ill-concealed layer of suspicion, expecting them to try to sneak their new products into production without proper handover or support.

In return the developers are trying to get the fruit of their labours into production because the reason they’ve spent thousands of person-hours putting it together is because the business case says it’s going to improve productivity or profitability, yet all they get from the ops team is a demand for more testing, more support, more documentation, more of everything.

Is this fair? Much of the time, yes. Have I come across cowboy developers who’ve lashed something together and fudged it into production? Of course I have, and I bet you have too. Have I come across ops managers who will find any excuse they can to bat off the developers so that they don’t have something new to support? Yup, no doubt about it.

Interestingly, a single word sums up my frustration as an ops manager when developers come to me to make something live: Agile.

Agile is, I reckon, a good thing. If you can produce something in bursts and get the benefit of the first while you’re building the second, and from the second while you’re building the third, that’s a great thing and much better than waiting forever for a single-hit delivery of a socking big monolithic monster. Not least because the world has probably moved on while you were building the monster and nobody wants it any more. Trouble is, Agile is far too frequently (and wrongly) used to describe poorly designed, poorly implemented crap that doesn’t satisfy the requirement because nobody bothered to define the requirement in the first place.

What about as a developer? Well, my frustration with the ops guys is that while we’re producing new software and systems that do new and exciting things, they have an overwhelming desire to try to fit it into their operations model with their fleet of processes and policies, thereby thwarting our attempts to do stuff differently and innovatively.

Both of these scenarios are understandable, of course. The ops guys have service levels to abide by and a finite amount of staff and time so spend on learning new systems, so you can’t blame them for resisting change. Similarly the developers will generally underestimate the amount of support and training required for a new product because they know it inside out and have become blind to how complex it actually is.

But what actually is the barrier to taking something live? Errr… none of the above, actually – they’re just symptoms of the problem. The problem usually boils down to a lack of common sense.

I mentioned a while back that the business case states that the new development is “going to improve productivity or profitability.” But what is actually in the business case? Chances are it’s all about the cost of the tools to build the product, the staff costs for the developers and testers, and so on.

But unless it’s a big new product (which makes it impossible to miss the obvious) how many business cases include six weeks of contractor coverage for the IT service desk while the team go on training courses for the new product? Or the budget for overtime to cover the retainer because the new development is the first you’ve made that needs to be supported out of hours?

Or the competitive bids from third party support agencies for the back-end database that you’ve had to implement with something non-standard because it has a unique, essential feature?

Business cases for new developments aren’t written by ops managers. Which means that the post-deployment bit doesn’t usually get the focus it deserves. Which in turn frustrates the hell out of the ops guys when yet again they have to work miracles with bugger all resource to take on the new system.

It’s a complete no-brainer, then, to suggest that to make a successful new development you need to involve the operations team from the start. Because frankly the only people who know operations properly are the operations team. Look at the ITIL framework – it starts with strategy then works through design and transition before arriving at operations (with continuous improvement catching the result at the end). Designers seldom have experience in operations, but a critical part of the design process is to understand what obstacles stand in the way of the new product working properly – everything from available computing resource to likely failure points – and how to design around those obstacles. And the way to do that as early as possible in the project is, fairly obviously, to embrace the people who know it all and live it daily.

If you have the ops team on board as part of the project, not only do you get the benefit of their knowledge while you’re building the product but they can also benefit from the developers looking in on ops from outside. It’s easy to be blinkered and have the “but we always do it this way” mentality when you have standard operational processes; having non-ops people in there means the status quo gets questioned and, in some cases, changed.

Think of the case where the ops team says: “We don’t have the resource to support that” and the dev team says: “So why not outsource it then?” If you ask that at deployment time, you’re stuffed. If you ask it at business case time, you budget for it and it’s taken into account from the beginning: occasionally the extra cost makes the project unviable, but usually it doesn’t.

Involving ops staff from the start also brings the final benefit of the concept of DevOps: working together makes it easier to stamp out the obstacles. One of the most eye-opening things you can experience is the first time you sit in a project approval meeting with the developers and the ops guys pulling on the same end of the metaphorical rope.

That’s partly because it’s amusing to see the surprise on everyone’s face when the ops manager smiles and says: “Yup, we’re happy with the support model and they’re including X, Y and Z in the design so it’ll interface into our monitoring suite properly.”

But it’s partly because for the first time ever the business case is realistic because it includes all the ops and support costs and is seen to have been thought out properly.

It also inspires confidence in the approval committee. For example I was once asked by a senior manager why I, as the ops lead, was happy to accept a service into production despite the third party support contract not yet being quite finalised. Easy answer: the developers had kept me informed all along and we’d all agreed (including the business owner of the service) that the benefit of going live immediately was well worth the risk of accepting a best efforts support model for a few weeks.

One thing you learn over the years is that you don’t have to have the best solution every time – what matters is that you can prove that you’ve considered the alternatives and made a positive decision to go with the chosen idea.

As a word, DevOps is at that tricky age where it has got a spotty face and braces on its teeth (not to mention an embarrassing camel-case infection) and sort of shuffles about looking awkward and trying not to make eye contact.

But is it, as a concept, a proper thing? Heck, yes. ®

Sponsored:
Global DDoS threat landscape report