Defining value in the age of Platforms and APIs - only scratching the surface

In the most recent part of my series?I was presenting some interesting APIs and automation capabilities. (Missed part one of my series?)

This article now concludes my series. A firework of compute models, even more AI and the inevitable #BigData we all love!

No matter the platform, there’s a computing model for everyone

Platforms and APIs and how you operate, evolve them depends on where they live and for example how you manage computation. (Networking and storage are other obvious concerns.) The compute model you opt for has a lot of impact on operations, service, flexibility as far as what you can actively influence. The trend is going clearly into the fully managed models with cloud functions as prime examples for serverless: a model that pushes infrastructure details into the background, often allows configuration of pre-allocated capacity but that’s pretty much it. Configuration and service details are deliberately kept abstracted away with the promise to keep up with demand and paying only what you consume. Here is how Google Cloud portrays the evolution of compute:

Serverless models and Platform as a Service (PAAS) models are usually well integrated, embracing event-based integrations which is another important trait besides automated resource provisioning. A new object arrived in your storage bucket? An event is fired which can be the starting point for a new processing step kicking off. For example, every time a picture arrives in your storage bucket, signal a serverless function – and auto-scale and crop that image, store it wherever it’s needed automatically. This way you could for example process user uploads or respond quickly to critical events, for example if the event origin is not a storage bucket but a monitoring service.

At this point in time (end of 2018) serverless functions certainly have their challenges: cold start-up times that reach into the hundreds of milliseconds, capacity limitations, timeout limitations, control over the underlying infrastructure. The latter at least is something to be expected and accepted as that is part of the serverless function nature. If your application is dependent on specific runtime environment conditions and you therefore need full control running containers make a lot more sense. There is some solid middle ground there with containers being managed on your behalf, for example via Azure AKS or AWS EKS. This way you can at least get around managing Kubernetes yourself, the de-facto standard container orchestrator.

Serverless functions are very cost efficient at lower volume and tend to get very costly at massive scale. With some clever planning and architecture however, you can bring down these costs tremendously. Troy Hunt is paying not even 8 $ for 54 MM searches a week, retrieving results from a DB of half a billion objects.

So here's the hard facts - I'm dipping into my pocket every week to the tune of... $7.40 for you guys to do 54M searches against a repository of half a billion passwords

(He is operating the pwned website which you can use to figure whether your data has been breached.)

A combination of architecture best practices and creative use of services linked up with each other allows him to run his service at scale with no trouble on his end.

For your info – Google Cloud Functions went generally available and features some extra-functionalities like pre-loaded system tools (like ffmpeg etc) and libraries. A nice little differentiator from other serverless functions that always ask you to package everything possibly needed with your function and maybe the direction AWS Lambda or Azure Functions may take.

AI and IOT services

As I have explained earlier, APIs are great for giving all developers access to trained (or not yet trained) AI models. At the same time, they are great tools for ingress (=absorbing) or egress (=fan out) of data. That matters a lot as far as Internet of Things (IOT) is concerned because of the sheer volumes at play. IOT could be anything from sensors to autonomous apparatus. Further, connectivity can be challenging due to the conditions these “things” operate under. What you want to achieve there is a high level of self-sustainability by processing data “at the edge” and at the same time apply machine learning with as little delay as possible while on it. Edge means the actual device itself, harnessing it to do at least some of the computation if not all instead of relying on a central service at all times. Azure IOT Edge is a nice manifestation of edge computation for IOT.

The good news is, that thanks to a range of AI services available via all the major cloud platforms building your AI powered IOT solutions requires only commodity hardware and a couple of dollars for testing out these services – usually there is some generous free quota so chances are you would get away using these services for free for a long time.

Build creative security cam solutions. There is nothing stopping you.

More on AI services

A great use case for APIs and Platforms are of course highly complex ML services that developers can consume and take advantage of, even without any ML background at all.

After all, ML + AI are getting democratized thanks to Cloud services from the big three.

For example, Google: https://cloud.google.com/blog/products/ai-machine-learning/closer-look-our-newest-google-cloud-ai-capabilities-developers

And just take a look at AutoML Vision that makes it dead-easy to train your ML models.

Eventually, it’s all about democratizing AI capabilities.

As far as recognition services go - transcriptions are still tricky as it seems, just gave AWS Transcribe a go on an interview recording with Matt from API University and stored the resulting JSON here.

And the same file with Google Cloud ML Speech to Text instead of Transcribe: here.

In either case, no matter which AI service you run - use with caution. We are still talking early days. (Watch this hilarious video mocking Siri.)

Nevertheless, a smart combination of AI services can yield amazing results. Check out this video showing off Image Recognition, Sound Recognition, Translate and Natural Language Processing demo in one go.

Platforms are always home to “Big Data”

Big data is a stretched, if not constrained term by now. It is tough to tell what constituted “Big Data” and the term has been misused often enough for sure. As far as dealing with massive volumes of data, parallelized intake and outtake of data it’s definitely a concern though. A “Big Data” situation is created early on in the lifecycle of any platform with all its APIs, and you can easily relate to that from your personal experience. I dare you to think about your collection of photos and videos you shot with your cell phone(s). Now take this over 10 years. Your mom’s child memory books have nothing against this volume. Without doing much you created massive amounts of binary data, plenty of metadata and more than likely different variations of every single asset.

By the time you uploaded them all that data crossed various APIs, API management systems. And of course platforms that would record, monitor and analyze the data on the go, scan the operational parameters like access times and similar for anomalies. By now you get already an idea of how big of a data footprint you created by “just” managing your everyday pictures and videos you took in the park, in the café, at home, wherever.

Cloud Platforms have their own “Big Data” services to cope with these demands, for example Azure Monitoring or AWS X-Ray. If you are building everything yourself, and I cannot emphasize enough you shouldn’t, you’d have to come up with solutions like that or in general for dealing with the massive amounts of data early-on. Not when your platform is already running. Creating these solutions is not trivial and while a very pragmatic “let us push this to Mongo” kind of solution “on a side” seems fit the bill at the time you want to get over with things, you’ll dearly regret those decisions in no time.

That becomes even more obvious if you intend to run some analytics on top of the accumulated data to extract useful, relevant insights. Helping you to apply improvements to your service or even better, sell more and better targeted.

Realistically you want to have clear separations of concern and push the data you need for analytics to the right services for intake/outtake. That should happen ideally not via batch files but via streaming data in and out. Batch file management is always a hassle when it comes to scheduling and management of sequences, certainly it does not help with timely processing where everything is going. Plus, applying a reactive event-based paradigm you want to deal with data as it is generated and only pile it up for the sake of temporary caching or synchronizing. Kafka is popular these days and can help you, proprietary services like Azure Stream Analytics as well of course. (Did you know that Event Hub supports the Kafka protocols seamlessly? Maybe your decision of technology does not have be either-or.)

Orchestration of services and data go hand in hand and gladly, there is enough choice to cover all your operations and analytics needs.

What platforms, services and tools to use to make sense of the data is a whole bigger question which I will not go into this article (series). It depends a lot on your overall system architecture strategy, available skills in your teams and the focus you want to put on the number crunching. The answer could be anything from AWS RedShift plus AWS QuickSight to Azure DataWarehouse and PowerBI to Google Cloud BigQuery.

I know that lock-in is always a concern, however the best possible baseline set of integrations and capabilities are usually only available if you make a bet and not try to keep everything agnostic by e.g. putting bespoke solutions into containers all over the place. Therefore, the services mentioned make a lot of sense for all the properties they have to offer. Think of pre-existing integrations with e.g. notification and alerting services, serverless function execution, pre-existing statistical models and much more. In case of BigQuery for example you would get an automated import of the Google Analytics data into BigQuery “out of the box”, to a low-granular level. Of course, PowerBI has great integrations with Azure storage solutions. You see, the best choice really depends on the holistic context.

GraphQL

If you are into APIs and API Management, you have probably already come across GraphQL. In a nutshell, think of it as a service bus interpreting GraphQL queries into native selections from all sorts of sources. That could be your relational DB or a mash-up of APIs, giving the developer a lot of control over what would be retrieved. Fantastic for defining exactly what you want to e.g. build your UI. Not trivial for state changes and persistence in general. Will most likely coexist happily next to REST APIs. It’s still early days.

A “thank you” is in order

Thanks for the kind support of Nader Dabit, Matt Biehl, Randall Hunt and Howard van Rooijen who all took the time to chat with me and/or support me in some way to find my path through the latest and greatest in the field of modern-day API development. They are all great folks to talk with, about a lot of things in fact well beyond the topic of this series.

And last but not least - get in touch

This was a long (winded) article series, maybe too long for LinkedIn. :) Anyway, I will package everything in a white paper shortly. If you went through the series, you received an awful lot of information about the platform economy, the crucial role of APIs and the democratization of capabilities formerly only available to big organizations with millions to spend.

And yet, we are only scratching the surface. Hopefully I have provided at least a starting point for your own journey. As every journey is different, and every context is different. What makes sense to the many cases I shared with you in this series by no means has to make sense to your specific business reality. I am fairly confident there are some take-aways for everybody, though. More than happy to brainstorm with you and of course, bounce off ideas. I am always keen to learn, you might need another perspective on things. We all win.