How to Build a Datacenter with Skyport Systems

What’s the reason why we should rebuild something already working from the beginning?
One of the reasons could be because we think that we can do it better, or maybe simpler, with our own base concept.

I attended during TFD15 as a delegate in Silicon Valley the presentation of a quite new, at least for me, company that decided to do this.
In this occasion, Nils Swart, Head of Product in Skyport, described their entirely cloud managed on premises virtualization platform built on a simple architecture but strongly secured.

This is the first of the sessions that Skyport presented – I’ll follow up hopefully with the other ones also.

Cloud managed on-premises virtualization platform means bare pieces of hardware, running on premises (HQ, Branch offices) close to the end customer. But now comes the interesting part.
It’s cloud managed: you don’t manage the server (called “SkySecure Hyperconverged Platform”) directly in console or remotely, but only through a “SkySecure Center Cloud Management Service”. All the servers, all the locations, centralized.

Then they took the 5 most important parts of a successful virtual deployment and combined them for us:

  • Virtualization
  • Storage
  • Security
  • Networking
  • Analytics

I consider this the main effort: just think at putting together, as a final consumer, an orchestrated hypervisor system (i.e. vSphere), a SDS (i.e. vSAN), connecting all this on a virtualized and secured network (i.e. NSX) and last, but not least, monitoring this deployment through a specific application (i.e. vROPS)

sky1

Skyport customers reside in 3 categories:

  1. Critical systems: the ones we need to carry out the everyday main tasks in any emergency, i.e. when connection to the cloud (and to the world) is lost. Here reside authentication systems, control platforms, DNS and so on;
  2. Hybrid Cloud Edge: this is a hook for the cloud, it means, applications that we like they run on premises but using bulk data that are not needed to be in our DC;
  3. Remote branches: same as the previous 2 points, but in RoBo

sky2

The challenge with Cloud is unfair: it wins. The similitude Nils used made me feel a little scary: Cloud Eats our existing DC. This changes the operation model too.

So, the bulk compute will move to the cloud, no reason to take space in our DC, with a couple of exceptions: the one that “should not” move, like High Value, Compliance, Latency. And the one that “Cannot” move, hosting legacy applications not able to run in other environments.

Then there’s the “security” point: the DIY datacentre security will fail because CIOs tend to over-rotate to cloud even if workloads don’t belong there.

sky3

In case of a single customer, proposing complex architectures as public clouds do, means rise his costs, directly and indirectly, and security would be affected also in this case.

Nils talk about a Vendor conflict of interest: they train us to make their product work, spending valuable time on details of infrastructure, but not on using the infrastructure itself. Well, I disagree in this point. At least for the field I got training, after a fair base that’s necessarily theoretical, the remaining part was and is practical, using day by day what I built.

But let’s come back to the session. The solution proposed is completely developed inside, so all the hardening guides, best practices, patches, upgrades, all is care of Skyport. This is strongly needed because if not, the difference of maintenance between on-premises infrastructure and cloud is far too large.

sky4

This means that as long as complexity remain, there’s no reason to stay on premises: cloud wins easily.

Together with the previous assumption about what shouldn’t and couldn’t be moved to the cloud, result is that the datacentre has to shrink, adopting a simple and secure solution for few servers, possibly maintained, that performs as an anchor point for the services that we decided to move to the cloud. Complexity is tightly correlated to Security: if the first arise, the second falls dramatically, and vice versa

sky5

The criterium to identify what is expected to be moved and what remains could be explained with the following flowchart:

  • can the app be moved, and no intellectual properties involved, so ok move to the cloud;
  • if intellectual properties are on, but no regulations prohibit cloud, again, go to the cloud
  • otherwise: stay on premises. On premises will stay also legacy applications that aren’t going to be rebuilt by now.

sky6

The concept that Skyport tries to apply to on premises deployment is to make the customer feel like if it is in a public cloud, but with the servers inside his datacentre. Skyport can realize this taking care of all the basic stuff – the yellow component in the image below, leaving to the customer the higher-level management, in blue

sky7

The next generation DC should be made of an anchor point to/from the cloud, plus infrastructure defined critical, plus legacy applications, and all of these 3 components to be replicated in case of branch offices or remote sites, all with the same standard of security, similar properties, similar protection, all of them managed by a central point.

sky8

The whole process should start looking at the environment, at what is or seems insecure and define so which are the critical systems. Then, move designated data to the cloud creating so a hybrid cloud environment. Lastly: manage the remote compute.

sky9

Advertisements

One thought on “How to Build a Datacenter with Skyport Systems”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s