Machine Learning + Transfer learning + tensorflow for Kaggle Comp

One of the things I'm currently doing with my time is predicting the future with machine learning. One thing I'm doing is a Kaggle districted driver detection competition. I recently posted some starter code for doing transfer learning with Convnets for others to use if interested. Check out the discussion and code at the below links.

https://www.kaggle.com/c/state-farm-distracted-driver-detection/forums/t/21552/starter-script-for-using-the-pre-trained-inception-v3-model-tensorflow

https://github.com/ckleban/kaggle-distracted-drivers-inceptionv3

Thanks

Chris

Cloud Services Redone - Part 2 of 2

Anywhere Cloud Services - Thanks to Docker & Kubernetes

Cloud Services without the Lock In 

Part 2 of 2 

In part one of this two part post I wrote about how open source software will be delivered as services instead of as binaries. These open source services will deliver a free, open, flexible service in which engineers can use to help build their applications without everyone all trying to solve the same problem of figuring out how to keep the software up and running. If you haven't read that post, I encourage you to read it before proceeding with this post. 

These posts will mostly describe a vision I have but will also include some back story and some technical information. The attended audience is anyone building or using applications. 

Where are Cloud services Today? 

Today's application level cloud services like AWS's Kinesis or Google's Big Table provide engineers fully managed services in which you can build an application on top of that require no effort to maintain. These services are secure, autoscaled, monitored, logged, integrated and updated. Personally, I love these services. But...

• You are locked into these services via your code (ie, changing database backends would need a software change)
• By choosing a public cloud service, you also are forced to use their hardware. What if you run on Microsoft Azure but love Big Table?
• What if you want to use open source software but you don't want to operate, scale and secure open source software myself?

Enter anywhere cloud services. 

Model #2 - Anywhere Cloud Services

An anywhere cloud service is a fully managed service that can be delivered anywhere and should have these characteristics:

It is fully managed - The consumer doesn't need to worry about keeping the service online. This responsibility is owned by the service provider. 

It runs anywhere - The consumer chooses where the service lives. This could be any one of the major cloud providers or a private cloud with a standard API. There is a clear separation between the entity running the infrastructure and the service running on top of it. 

It is consumed as a service, not as software - It provides a function to the consumer in a clearly consumable method. Ie, a NoSQL service provides a way to insert data and retrieve data. The services heals itself. It scales when required. It provides metrics, logs and alerts to the consumer. It is highly available. The service is installed as easy as running a command or clicking on a button.

Give me some Examples...

To help illustrate this idea, here are a few examples that we might see in the future:

• Any of AWS's non-infrastructure services, like the NoSQL DynamoDB service, can be provisioned in all of the other cloud providers. Ie, Azure, GoogleCloud, Etc. 
• Google's non-infrastructure services, like their PaaS App Engine, can be deployed on any public cloud or even in on-premise data centers via openstack
• A startup goes after the Docker container space by building a service that will run your application/code on any public or private cloud. 
• A development team decides on a data stack of Kafka, Spark and Cassandra because they want the benefits of open source software. However, they don't want to pay consultants or do operations themselves. So, they use a new service made by a startup that specializes in delivering these software stacks in any location desired. 
• Creators of open source software will package their software up so that is can be easily deployed as a service in addition to supping the source code and binaries. Companies will also offer 'supported' versions of these services at a cost. 

All of these are possible, thanks to Anywhere Cloud Services

How do we get to Anywhere Cloud Services? 

Their were two big hurdles to Anywhere cloud services:

1. Standard and efficient way to package and deploy software services across the multiple cloud providers and on premise hardware
2. Efficient way to package, run, deploy, scale and secure your services (NoOps)

Enter Docker and Kubernetes!

Docker enables us to easily build, ship and run software by packaging it up in a way that will run on a wide range of systems. By using containers, cloud service providers can run their software in any environment. But, that isn't enough. We need a way to get that software installed, working and highly available. We need something like Kubernetes. 

Once the software is packaged in Docker containers we can turn their software into services by using kubernetes's features. Kubernetes's goal is to take a set of infrastructure (that lives anywhere) and provide an API to create services on top of that infrastructure. Kubernetes includes features like load balancing, scaling, rolling-updates, service discovery, name spaces, APIs, scheduling and configurable infrastructure threshold limits. Using these features, we can create declarative services and give control of the service to the consumer. Kubernetes provides the No in NoOps while providing developers a single API to launch into both public and private clouds. 

How will we consume Anywhere Cloud Services?

First, consumers will need to have one or more kubernetes clusters. Getting kubernetes up and running can take as little as 5 minutes or as long as a few days depending on your situation. Kubernetes supports most public clouds, openstack clouds and on-premise data centers. Consumers can also choose whether to run on top of VMs or physical machines. We can run kubernetes ourselves or we can use a managed option if we are looking for increased support. 

Notice that the consumer is in complete control here of where their applications will run as they will be freed from any lock-in. Thanks to the common API that lives in any infrastructure environment, consumers can use these clusters to deliver on a multiple cloud provider strategy or they can create a true hybrid strategy.

Second, consumers simply consume these services by having these services deploy their code into the customer's Kubernetes clusters. Either through an app-store like experience or through a developer friendly like experience, users will search for a service that meets their needs and click install. The service provider would than reach out to the Kubernetes cluster in question, either in the cloud or on-premise, and install the service. Developers could than immediately start using the service. The service provider's job is to ensure the service is running, healthy and scale it as required. 

In this new world, consumers will have more control of their application and the services that they depend on. They can move our applications between clouds or between private and public. Consumers can run their applications actively across multiple clusters or do active-standby. All this is sweetness.

In summary, Anywhere Cloud Services

With anywhere cloud services, developers will be able to build their applications the way they want while not having to worry about running and operating all their back end services. Tech execs get freedom from cloud lock-in and have a path to a true hybrid solution. Public cloud providers get access to customers on other clouds that don't want to move. Open source projects get a new path to revenue.. Entrepreneur's get a brand new gold rush as their are plenty of challenges and opportunities.

In summary - Anywhere and Open Source Services

In 5 years, cloud services will be just like software in that you go buy some and install it where you want. Pretty easy. 

Thanks
Chris Kleban
Twitter: @kleban