Thursday, January 28, 2016

An Interview with Derek Collison, Apcera’s CEO and founder


I interviewed  Derek Collison, This is how SandHill.com describes him
Derek Collison is founder and CEO of Apcera. An industry veteran and pioneer in large-scale distributed systems and enterprise computing, he has held executive positions at TIBCO Software, Google and VMware. At TIBCO, he designed and implemented a wide range of messaging products including Rendezvous and EMS.
Derek is not from an Ivy League University (he graduated in University of Maryland) , yet his career is a string of visionary projects in distributed computing that brought immediate tangible benefits.

As Walter Isaacson, the biographer of Steve Jobs wrote in New York Times,
Smart and educated people don’t always spawn innovation. America’s advantage, if it continues to have one, will be that it can produce people who are also more creative and imaginative, those who know how to stand at the intersection of the humanities and the sciences.
Paraphrasing another comment from Walter Isaacson, "intuition was based not on conventional learning but on experiential wisdom. He also had a lot of imagination and knew how to apply it"

Mr Isaacson spent months next to Steve Jobs. I spent a few hours with Derek Collison and it felt as if these words were written for him as well.

Apcera majestic Art Deco office building in San Francisco 

The User Problem 

Miha: What is the user problem you are trying to solve?

Derek: At Tibco Software,  between 1999 to 2003, we were experimenting with high-speed messaging, integrations, middle-ware and so on. Even at that time we started to see how we can get a lot of resources together, to get something done. The message bus or integration bus was put together in a big fat app – for Wall Street.

Miha: Then you went to work for Google.

Derek:  Yes. I spent six years (2003 to 2009) there I was watching the development of web, and mobile, coming out. In addition to building survey apps and  windows apps, engineers had to build web apps. At the time, it was kind of horrid. Ruby on Rails came around this time, to try to solve and simplify building these new web apps. It became interesting to me to watch how the deployment become harder (and I mean very, very much harder) while the development became faster and easier.

Miha: This is was really a game changer

Derek: Google came up with new rules

  1. Hardware does not talk to software
    • Hardware was not an issue; we had a sea of infrastructure 
  2. There is no hardware for testing or hardware for production but just one big cloud.

And software people like me, we did not talk to machines, we talked to an Intermediary platform called the Borg.

Miha's note

See Wired Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon ...the software system that orchestrates the whole thing ... is called Borg, and it’s one of the best-kept secrets of Google’s rapid evolution into the most dominant force on the web. [Google engineer] John Wilkes won’t even call it Borg. “I prefer to call it the system that will not be named,” he says.
 In 2014 Google decided to offer Kubernetes  as an evolution of Borg The developers from Borg moved to  Kubernetes  team. Google's Kubernetes is now part of  OpenStack.  

Derek:  The Borg was very rudimentary at the time, but it did something that made me feel empowered, Google trusted the BORG, not me ☺ . They trusted that platform of technology to protect their core business, and allowed us in software development to move fast.

Miha: How did Borg work?

Derek: The Borg principle was "Convention over Configuration".  It means a developer only needs to specify the unconventional aspects of the application
Google started to do the same thing to deployment. I was not involved, but they had a project called Google App Engine  which as a platform offers a limited number of choices for deployment, but it is much easier to use

Miha: How did it work in practice?

Derek;

  1. Let Google worry about database administration, server configuration, sharding and load balancing. With Traffic Splitting, you can A/B test different live versions of your app. 
  2. Choose the storage option you need: a traditional MySQL database using Cloud SQL, a schemaless NoSQL datastore, or object storage using Cloud Storage. 

Multitenancy support lets you compartmentalize your application data.
[This is called “opinionated stacks” like “opinionated software”]
Miha: How come you then left Google to join VMware?

Derek: When Paul Maritz succeeded Diane Green as CEO,  he knew of our team at Google. He came over and said:  “I need you guys to come over and do something cool in VMware”. I personally was not interested in virtualization, so I came up with a new idea called project B29. This was  an enterprise PaaS (Platform as a Service). It had to do with Java applications, with appservers and databases using some sort of opinionated stacks.

As soon as the platform was launched I sat back and said to myself, “I missed the bigger and harder problem”. The bigger problem was not to speed up deployment, but to deliver a trusted platform, seamlessly and transparently.  In Google we had Borg, but what about the outside world? Here we have devs and devops, running separately from each other, deploying the most modern technology, which today is Docker containers, tomorrow who knows what that will be. This is not the hard problem. The hard problem is how to get over security and trust which allows both devs and devops to deliver faster.

Miha: Docker security is a big issue now,

Derek: Of course. When we started the company, I said: “Hey, the security system the way they work today (firewalls, VLANs), they are not going to work or scale to fit in this new world. They are too slow to respond, we need a better way to do this. This is not just about container security standards, like in the OCI (Open Container Initiative) that Apcera joined. It is not about scheduling smarts (BORG was not very smart, it just matched some constraints), but it did the job since 2003 and it was still a preferred tool inside Google.

How Apcera Started

Miha: When did you start Apcera?

Derek:  In 2012, VMware open sourced the project, delivering a technology that did what it said it did. From the interaction with the customers, I discovered that we solved the wrong problem, yet the train had left the station. It was not like Cloud Foundry 2.0 where I can do a re-write and try to solve a different set of problems. Devs and devops are all about speed and innovation and all new tools. But in my opinion, they do not see the forest for the trees. I realized this was not about speeding things up; it is how to have a system that reasons and decides those things transparently, and enforces those decisions and policies  to drive trust. How do I reason if you are allowed to deploy something? How do I reason to whom you are allowed to talk?

Derek paused for a few seconds:

Derek: Back to VMware, they created a system that in my opinion  allowed OpenStack to exist.  By that I mean not race to reduce costs as much as possible, but offering a class of  services that attract  me to move from one cluster to another. I think most of those services will be around data services, human machine interfaces, and Artificial Intelligence and Machine Learning.

I have two options: I can either (1) Hire expensive experts from IBM or Amazon, for example, to create all these services, and greatly increase the costs, or (2) create a platform that overrides the complexity to  move services  from one cloud to another

Bottom line, you can have a platform that over-rides all this costly and complicated stuff. For example, we support containers from Docker, directly from Docker, there is no code from us, that allows transparency.  Once you are running on that platform you have a true, trusted app mobility and scalability. in Vancouver at the OpenStack summit 2014 we were showing how we change the policy to run on Google, then move to Amazon, and then back to OpenStack, all in about a minute. Before it took months. Docker solved a lot of the porting stuff. Apcera can help you move the workloads from one cloud to another and will enforce trust: where things are allowed to run, what it is allowed to use and to access, and who is allowed to talk to the workload, etc.

Apcera's new office inside

What Apcera Does

Miha: Who sees Apcera? Devs? Devops? Users?

Derek: Great question. If devs and devops see us, we would have failed, because we would have had exposed the complexities of managing policies and operations and slow down the development and deployment.  We enable the IT Operations to become the heroes, who almost on a daily basis put a platform together, so dev and devops can go ahead with no worries.

Miha: Some engineers don’t believe in devops. What is your opinion?

Derek:  We believe in Apcera that we are taking on some really nasty and hard problems, to make it transparent and enable IT ops to say, “yes, you have an interface to our system and you understand policies, watch the change in policies.”  In an enterprise, the devs and devops are just a target for the Docker containers, of for the Kubernetes ecosystem… but it is  Apcera who designs and enforces all the rules of the platform.

Miha: Kubernetes  is now part of OpenStack, Apcera wouldn’t have any problems administering their workloads?

Derek: Yes. The devops have no direct access to the Apcera platform, but they benefit from it. Devops are very smart and hard to find. But the issue is not smartness, it’s awareness. The guy who runs IT Operations, he reports to a chain of command to privacy gatekeepers, who are aware.  You don’t have to encrypt the database. We just make a rule that says, any data in the database has to be encrypted.

There are two way of doing this. One is to go to every dev and devops and say, please recompile your apps to implement this and that, or you can a have a platform technology to enforce the policy. That is a very hard problem technically to do, but if you can pull it off, there is this #1 consumers electronics company who says: “Guys can you do this for me?”  and we can.

 There are some immediate problems, while not very sexy, they are very important. For example, a customer said to us, “I have this simple problem:  we had this task of porting 4,800 applications in Java 1.6 to port  to Java 1.7 which had an implementations plan for 18 months, using three groups of about 200 people. The customer was not sure how they would verify whether they run on Java 1.6 or Java 1.7 with confidence after the 18 months.  Can your platform tell me who is running 1.6?” I said yes. He says, “how can you help this process?” And we answered, “if the platform enables you to cut down the implementation time from 18 months to 2 months to have all this stuff done. Then you can trust the platform that the data goes in the right place, etc.”

Apcera's team "Nice people to do business with"

Some thoughts

Peter Linder, a Networked Society evangelist at Ericsson, says Distributed data centers are  the new network end-point. "These distributed data centers will be a mission-critical infrastructure for Networked Society."

Derek seems ahead of his time, in the right direction, because Apcera, as it is now, might be just the first stop in his journey.

Disclosure

I don’t say anything online that I wouldn’t say in person.  What I say are exclusively my thoughts, views, opinions or understanding of a topic or issue, and not my employers'. I can be wrong even though I try hard not to be. I will admit to mistakes, correct them promptly and even apologize where it is appropriate.
Post a Comment

Blog Archive

About Me

My photo

AI and ML for Conversational Economy