No comments

CFD1 Prep: Cisco

  By Justin Warren 11 September 2016 , , , , , ,

cisco_logo-svgCisco are well known to me. but the topics they’ll apparently discussion with us are not.

Container networking is on the agenda, which should be really interesting, given how Cisco is seemingly so tightly welded to its hardware when containers are almost completely abstracted from the hardware. Networking containers is going to become a big deal, because of two major trends (that I just wrote about for an upcoming issue of CRN Australia incidentally): the decoupling of networking hardware and software, and the rise of automation and orchestration.

Cisco is already moving in the software-defined direction with UCS and ACI, but it’s still centered in hardware. There are loads of startups that are working on the “switches are just servers with lots of Broadcom Trident II chips” approach backed by the Open Compute Project and ONIE. Just like we’ve seen in server land, the purchase of hardware is separate from the software selection. Linux and Windows will both run on a variety of x86 based hardware from a variety of vendors, and that fact has spawned a huge number of startups doing software and HCI type things, not least of which is VMware.

And as we saw with the decoupling of operating system from hardware that virtualisation brought us, we’re starting to see virtual networking operating systems pop up. I expect to see container-based version of the idea as well. Imagine if a firewall config change was a rebuild/recompile and deploy the way Docker applications are done today? What about a BGP route-reflector?

We’re also going to see a sprawl in container-like entities an order of magnitude worse than what we have now with virtual machines. They’re small and designed to be deployed en-masse. Of course we’re going to see loads of them sitting out there doing whatever it is they do, and they’ll all need to be networked somehow. The only way to cope with the sheer volume will be through automation, because humans just can’t handle that sort of scope cost-effectively, and we’re already seeing IT staff-to-device ratios come way down.

This is as it should be, because manually updating ACLs or routing tables entries is boring and humans are bad at it. I’m still somewhat agog at how long it took the networking world to ditch telnet for ssh, and even then the CLI continues to rule supreme when it’s a tedious and error-prone way to configure hundreds of devices. I recall using Tcl/Tk script to automate MPLS VPN rollouts back 15 years ago (also the Java-based hell of Cisco’s VPNSC product, but let’s not go there) so why oh why isn’t everything REST API based already?

Happily Cisco have some modern tales to tell here, as they acquired cloud management software startup CliQr not long ago. That’s also on the agenda for a chat, and I really want to dig into this more, since I’d just heard of CliQr before the acquisition.

There’s also Metapod, Cisco’s converged insfrastructure/cloud-in-a-box version of OpenStack, so that could well be interesting, not least to get a handle on how people are deploying OpenStack in the enterprise, and how it links into existing systems.

How Cisco is going to pack all this into their session will be a challenge, but I look forward to it.

1 Comment

CFD1 Prep: Druva

  By Justin Warren 10 September 2016

druva-logo-300

Druva is completely new to me, which is always fun.

A quick bit of research shows they’re aiming at the backup and recovery market, and the cloud angle comes from the software backing things up to either AWS or Azure. They appear to handle servers, VMs, endpoints (phones and tablets) as well as file sync and share, and cloud-based data like Office365, Salesforce.com, Google Docs, etc.

It looks like the secret sauce is some form of global deduplication to reduce the amount of data that needs to move over the WAN, which is an important hurdle that is often overlooked in bandwidth saturated places like the US (although tell that to T-mobile in the Valley, hah!).

There are two main sub-brands: Druva Insync, which seems to be the backup and recovery product aimed at laptops, mobile devices, and SaaS data, and Druva Phoenix, which looks like a more typical server type backup and DR type product that backs up servers and databases, and converts VMs into Amazon Machine Images so you can start them in the cloud if the primary goes pop. It looks like there’s an on-site version as well, but it’s called On-Premise, so automatic fail there.

The trouble is, I’m having trouble figuring out how Druva does all this. The Druva website is full of fluffy marketing writing, but is very short on actual details. It looks very slick and shiny, but there’s not a lot of depth here. I’ve even gone so far as to download some of the datasheets, but they’re similarly fluffy.

You can tell Druva Takes Security Seriously™ because of all the badges they have on their website. It’s certified secure! It’s enterprise grade! It uses something called Envelope Security, so I’m totally convinced.

I gave up some fake information to download a 451 Research analyst report from the website, which is more than a year old now, and it said that Druva came from endpoint backup land and was specialising in governance and chain-of-custody type legal hold stuff. That has a lot of appeal to executives with money, and I concur with the author of the report that this would contribute to Druva’s ability to differentiate and win large enterprise accounts.

The report appears to date from before right about the time Phoenix was added to the portfolio, and so server backup and DR was still very new for the company, as was the Office365 integration. That was over a year ago, so I’d expect quite a bit of progress has been made since, but I get the impression that the company marketing leading the product, certainly going by the website.

No doubt we’ll dig into the details during CFD1 and try to get some clearer answers about what Druva really does and what makes it special.

I swear, every time I turn around another four backup and recovery companies spring up as if from nowhere. There seem to be so very many lurking out there, it’s really hard to differentiate. Perhaps there will be a Great Reckoning, as is coming for the all the primary storage companies, and we’ll see some consolidation. I know there’s already been some, with EMC buying Spanning Backup, and Datto bought Backupify not too long ago, so perhaps the time of Reckoning is already looming.

1 Comment

CFD1 Prep: Scality

  By Justin Warren 9 September 2016 , , ,

scality_logo

I was only peripherally aware of Scality until last week when I attended the Scality presentation at Tech Field Day Extra at VMworld 2016. I came away impressed.

Jerome Lecat is an entertaining presenter, but the product is what impressed me. Scality make a software-only scale out storage solution called the RING, so-called because of the ring-topology at the heart of its architecture.

I’ve dug into the details courtesy of a technical whitepaper you can get from the Scality website for the low, low price of fake contact details. It’s a fairly straightforward multi-layer architecture where each software layer performs a specific function.

The protocol at the core of the RING architecture is based on Chord, introduced in a 2001 paper from MIT [PDF]. It is reminiscent of other scale-out protocols like PAXOS or Raft, but it seems to focus on an ability to scale to very large number of nodes without needing to know about the overall state of the network, just the status of a subset of nodes that are nearby. Scality have made their own extension and adaptations to Chord, and used it as part of the overall storage service.

Layered on top of this core functionality is some policy based data protection (replication and erasure coding based) and self-healing capabilities. The erasure coding implementation keeps the data chunks intact, adding parity data, rather than re-encoding the data as intermingled data+parity chunks. This speeds up reads, and means the relatively costly erasure coding calculations only need to be performed on rebuilds.

Accessing the storage is performed through an access layer (funny that) using Connectors. Scality has an object storage heritage, but the underlying object store also has a native scale out filesystem called SOFS that uses an internal distributed database called MESA to store the file metadata (inodes, directory hierarchy information,etc.). It’s not clear to me how SOFS/MESA and the Chord keyspace and distributed hash table interact, so there’s something I can ask during CFD1.

Scality uses an AWS S3 compatible API as well as its own native REST API for object access. AWS S3 is the de facto standard for object storage access now, so we should all just settle on the basic semantics of the protocol and move on. Scality also supports OpenStack SWIFT and Cinder, but also Glance and Manila somehow, which intrigues me. I’m not an OpenStack guru, so I’ll be interested to hear more about how Scality interacts with OpenStack in these different ways.

Scality also supports NFSv3, SMB 2.0, and Linux FUSE for filesystem access, which talks to SOFS. Scality claim this is an improvement over some competitors that use a gateway approach to filesystem access, but really the Connectors are a gateway to the underlying system. The gateway mechanism is just baked into the product, so yes it probably does provide some advantages, but again I’d like to know more.

It’s still pretty great that the one system can speak all of these different protocols. There’s no block access, but I’m ok with that, because LUNs are stupid and need to die.

RING v6 adds a bunch of enterprise features as well, such as Identity and Access Management through Active Directory integration, and Single Sign On via SAML assertions. These kinds of features make systems more attractive to enterprises because they can interoperate with the existing infrastructure, processes, and systems that an enterprise already has.

Newfangled startup things are fine for point solutions where you really need something new, but once you start extending into the rest of the organisation from your comfy toehold, you start needing to play well with others.

Scality are definitely one to watch, and I look forward to learning more about them.

No comments

CFD1 Prep: Docker

  By Justin Warren 9 September 2016 , , , , , ,

Next week I’ll be participating in the inaugural Cloud Field Day put on by Stephen Foskett and his merry band of Tech Field Day folk in Silicon Valley. As is my usual practice, I like to spend some time preparing for these events and learning a little about the companies presenting.

small_v

I’m already aware of Docker, but I can’t say I’m particularly familiar with them. Learning more about the details at Tech Field Day Extra at VMworld 2016 last week was certainly useful, and I look forward to getting deeper into things.

I also recently discussed Docker and containers on several episodes of The Eigencast. In episode 020, Red Hat’s Lars Herrmann and I discussed how the container image format isn’t the part of Docker that most interests me. It’s the way the technology acts as a forcing function for the people and process of organisations who adopt containers as a deployment method.

Immutable deployment units forces developers to completely rebuild everything whenever something in their application changes, which help to keep production in sync with development. Containers aren’t required to make this happen, but they make it easier because the technology enforces discipline, rather than depending on humans to have discipline. Humans suck at discipline, as I can personally attest.

The processes used for container-based application development also decouple teams from one another in specific, known ways. Again, this is completely possible if IT teams have the required skills and discipline, but guess what? They don’t. Containers fixes this issue, and also makes the solution portable across organisations. This is great for scale. Imagine if every organisation had its own programming language, instead of there being relatively few standard ones like C, Java, Python, etc.

Externally imposed standards force organisations to use a specific set of tools and processes instead of allowing them to have choice. All that choice has resulted in both poorly implemented systems (ITIL anyone?) or analysis paralysis as organisations constantly try to figure out what the best option is, instead of adopting a process of continuous improvement where things constantly get better incrementally.

The critical issue for Docker is that their way is just one way to achieve this overall goal, and there are plenty of competitors (e.g. Kubernetes) who would love to take over. Docker the container standard is one thing, but Docker the commercial entity is quite another. To remain viable, Docker the company will need to find a way to get people to pay for what has so far been given away for free.

It’s possible they could become the VMware of the new container-based world, but is that thinking big enough? Or is more modest commercial success enough? Will the investors who have so far tipped over $180 million into the company settle for anything less than a massive payoff? Will Docker manage to find an ongoing source of revenue big enough to justify this sort of investment?

No comments

The Eigencast 020: Containers With Red Hat’s Lars Herrmann

  By Justin Warren 8 September 2016 , , , , ,

Podcast (eigencast): Play in new window | Download (Duration: 51:35 — 70.9MB)

Subscribe: iTunes | Android | RSS | More

The Eigencast

Lars Herrmann, GM of Integrated Solutions at Red Hat

Lars Herrmann, GM of Integrated Solutions at Red Hat

Justin talks to Lars Herrmann, GM, Integrated Solutions Business Unit at Red Hat, about containers and enterprise automation.

In this wide ranging conversation, they cover how Lars originally got into open source (he was trained as an economist!) and how Red Hat’s business model attracted him to the company.

They discuss how containers aren’t new, and compare and contrast the various ways they’ve been used in the past, and talk about what’s different this time around. It’s not so much about the technology as the business processes that the technology forces you to use.

They talk about the differences between virtualisation and containers, particularly things like duplication, overhead, and security isolation. They discuss how enterprises are stuck using old processes, despite virtualisation allowing for new ones, and how this has created a management headache.

Car analogies are used with much relish, and there’s much discussion of the Toyota Production System (one of Justin’s favourite topics) and how the current IT industry changes mirror those of the automobile industry in the 1980s.

Finally they talk about the rise of the IT factory, and how the IT machine will require very different organisational structures and processes to what enterprises have used before. It’s an exciting time to be part of the industry.

Chapters

  • 00:00:00.000 Intro
  • 00:00:15.856 Episode Intro
  • 00:03:09.881 Interview
  • 00:07:13.470 RHEL7
  • 00:10:36.528 Containers Aren’t New
  • 00:16:47.676 Duplication and Isolation
  • 00:20:05.951 Change is Constant
  • 00:23:20.151 Technology as Forcing Function
  • 00:28:51.166 ITIL for Cloud
  • 00:30:59.221 Germans and Car Analogies
  • 00:34:29.919 Non-malicious Snowflakes
  • 00:39:05.470 Rise of The Machine
  • 00:49:59.433 Outtakes

Links

Sponsors

PivotNine-cropped-logo

This episode of The Eigencast was sponsored by PivotNine. Research, analysis, advice.