All Things API With Adrian Cockroft
This weeks All Things API Interview comes from the “most visible man in cloud computing”, Adrian Cockcroft. Cockcroft, previously the chief architect of Netflix’s cloud services, left the streaming startup to join Battery Ventures, where he is now a technology consultant.
Try Cloud Elements
He has had a long career working at the leading edge of technology, is fascinated by what comes next, and speaks extensively on a range of subjects. At Battery, Cockcroft advises the firm and its portfolio companies about technology issues, while assisting with deal sourcing and due diligence.
Cockcroft shares his knowledge on cloud computing and the importance of APIs.
Q: How did you get to where you are today?
I am mostly notorious for being the cloud architect for Netflix. I travel extensively to talk about what Netflix was doing and the importance of applying cloud solutions towards business problems at scale. About a year ago I left Netflix and joined a venture capital company: Battery Ventures. I am more of a technology consultant within the firm and spend a lot of time at conferences evangelizing and discussing DevOps, micro-services and fast delivery. The talks I gave last year were based around continuous delivery and developing faster. There is a lot of interest in these topics and I can recommend a recently released book on this subject; Lean Enterprise by Jez Humble. The book talks about how Enterprises are re-engineering and moving to DevOps, so that they can be more agile and responsive to business needs.
Q: What types of companies do you consult with?
My consulting covers portfolio companies Battery has invested in. It is often SaaS vendors that have a product that needs to scale and become more available, and they need help speeding up development processes. I also spend time with big end users and large brand name companies that are struggling to try and transform themselves.
Q: Why is there still hesitation in the switch to the cloud?
There is less hesitation as time goes on and more people figure out how to use cloud, while the cloud vendors add more and more useful features that are hard to duplicate in the datacenter.
You’re starting to unveil some research about why companies are choosing or not choosing to build into the cloud based on cost. What are you finding from the cost optimization standpoint?
Cost optimization comes down to a few things. The most fundamental cost optimization with the cloud is that when you’re using the public cloud, once you turn something off you stop paying for it. People are not used to designing systems that shut themselves down regularly or that are always running busy. For example: test and development environments. Your developers are probably working 40-50 hours a week, but there are 168 hours in a week. Over ⅔ of the time systems are sitting idle. If you are using cloud with Docker, you can pack lots of short lived test systems into a small number of cloud instances and shut down the testing environment when it’s sitting idle, which saves well over half of your budget.
The other aspect is that AWS in particular has a very flexible cost model, but people don’t know the various way you can optimize it. In my talk I explain how to consolidate accounts and reserve capacity to more than halve your costs.
You can also keep resizing your instances to the right amount of memory and CPU that you need, and autoscale the number you run based on customer activity. Savings compound together, so you could end up spending 10-20% of what you thought you might be spending, and there are fewer hidden costs and overheads compared to on-premise configurations.
Q: As more applications are built optimized for the cloud by using APIs, is there any cost for organizations building fully RESTful APIs?
The move to microservices tends to encourage RESTful APIs. Each cloud service has an API with microservices, versus the traditional app built around a front-end web page using a whole bunch of Java files or PHP. You have a lot of distinct services that do one thing and have to think more about interface stability and versioning (or API Management). The most interesting thing from an API point of view right now is the evolution of managing and deploying to a DevOps model. Every engineer writes a REST-based web service and they then own it all the way through to production. They’re doing this instead of writing a Java jar file to pass off to the test and ops people to deploy. This is the DevOps and microservices way of doing things, which is great for developers as they can update the code as often as they’d like.
There is another effect that happens when building microservice based applications. Over time, the front end APIs (like the core external API or website itself) become bigger and bigger, and end up not being microservices anymore, but more of a monolithic application on it’s own. The Netflix API server is great example of where that happened. It had all of Netflix’s dependencies on this API on the front end. This can be solved by adding an API proxy layer to the front end, and Netflix built an open source project called Zuul. Zuul was designed to export something that looks like the full API, but routes traffic to all of the individual microservices. This is a useful technique, if you are taking a monolithic API and trying to break it down to microservices you usually need to put an API proxy tier in front. It also helps you manage authentication, versions, users, regions, etc.
If you’re building something new you should start with API proxy of some kind and build everything behind that. Proxies become a key way to virtualize your API.
Q: As you’re advising organizations on how to use these microservices are they building them out for an internal use case or for the external facing products?
It’s both. We have reached a point where people expect products to have APIs. If you launch a new product that doesn’t have APIs, people will ask what were you thinking? The value of products nowadays comes from being able to cross integrate functionalities and integrate. Cloud is really just an infrastructure with an API so you can automate all of the things you need to do.
Everyone will build both, external and internal APIs. The external API is for integrating with other people and other companies. The internal API should be used to get between the microservices. They are a little different in that the external APIs need extra stability. For example, Netflix users have TV based devces in homes that are talking to the Netflix API. You need to be very compatible because external users use many different devices that need different versions of the API. You cannot assume their TV technology will take an update. The internal APIs are more flexible because you can find everyone at your company using a version of an API and ask them to upgrade, or make assertions this version will never be used again and shut it down. The versioning is different between external and internal APIs.
Last, you want to have a very efficient encoding and decoding process. JSON is much faster to process than XML and is easier to understand so it’s ideal for external interfaces. Between microservices it’s common to use Apache Avro, Google Protocol Buffers or Facebook Thrift for lower overhead and more compact encoding. The latest and fastest way to do this is called SBE or Simple Binary Encoding.
Q: Product development is being impacted by the trending proliferation of APIs. What is your advice to help developers drive adoption towards their APIs and Integrations?
It is possible to build APIs that are a pain to use for developers. There are two or three steps I recommend when aiming to drive user adoption:
1. Discoverability:
You need to be able to find if the API exists at all. How do you do that? A lot of times you go searching on GitHub. So put yourself in your audience’s shoes and be sure you’re considering what it is that they would be searching for.
2. Once you’ve found the API exists, how long does it take to figure out how to use it?
A lot of that comes down to having good examples and documentation. Again in your users shoes, confirm that the API that is actually structured to be used. A lot of times APIs are structured to just reflect what is there. It is like engineering documentation that describes every feature and nothing that ties it all together. When you are trying to program to an API there is a flow like Authentication→ Request→ Follow-up Responses. You need to document and provide code examples to show how users can flow through into a system and get things done.
3. Some APIs are just a pain to work with:
The XML and SOAP view of the world is logically consistent but it is annoying and hard to work with. The other view of the world is easier but how you structure your API and versioning is important. Sometimes trying to find the best practices is a bit of a minefield. One of the best thought out strategies is the Google family of APIs. They have a very standard API pattern, you look at the service and when you find a totally different service, the structure seems familiar. Whether it is google maps or google cloud – they have a common structure which is a nice way of approaching it.
AWS is the opposite. The APIs are all over the place and it is harder to figure out how to move from one AWS product to another without getting confused. They are able to work faster with less coordination across the company, which releases products quickly instead of taking more time to add consistency across the company. There are definitely tradeoffs between the two approaches.
Q: What are some of the trends you are seeing with APIs?
A mobile-first strategy is becoming increasingly popular because people are starting to interact more with companies through their mobile devices (which is API driven). The ability to automate everything you do including the hardware devices and provisioning through cloud and platforms is important. In order to get the IaaS hardware and PaaS deployment platform, API-driven means developers need to be familiar with APIs. At least they need to be more API-driven than they needed to be 10 years ago.
The post Are You Building a Monolithic App with APIs? appeared first on Cloud Elements | Cloud API Integrations.