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

Cloud Services Redone - Part 1 of 2

Disruption in Open Source Delivery, the Open Source Service 

What if we took the positives of open sourced software and merged them with the positives of cloud services like DynamoDB, BigTable, Kinesis, Lambda and S3? We would have a disruptive service delivery model.

In a two part post, I'll talk about two new approaches to delivering software as a service so that engineers can build better applications. One model I will call Open Sourced Services (Part 1) and another model I will call Managed Anywhere Services (to-be-written Part 2).

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 we today?

Today's Cloud Services 

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. Engineers can focus on their particular applications versus worrying about things like mysql cluster management or file replication. Personally, I love these services. However, these services lock you into a single cloud vender and you loose control of the functionality of these services. What if we could get the benefit of services without the lock in?

Today's Open Source 

Open source software has many benefits. The source code is open, which gives you increased control. The software is free which helps drive adoption and potentially lowers cost. It gives back to the community by enabling the free re-use of software. And it frees you from cloud lock-in as you can easily more your solution anywhere. However, open source software is normally delivered in a software package in which someone needs to install, monitor, configure, scale and upgrade so that it can be used in production. Each company often does all this a different way and their work isn't reusable by others. Isn't that a shame? What if we could take the increased control, the re-use of code, freedom from cloud lock-in and the free price tag of open source software but deliver it as a service?

Well, what do we want? 

The three main items that stick out are:

• services
• control 
• portability (no lock in)

Below, I will talk about one way how we can get there. 

Model #1 - Open Sourced Services

An open source service is the packaging and delivery of open source software such that it is delivered as a service. An open source service should have these characteristics:

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.

It is controlled as a service, not as software - The consumer takes action on the service itself versus it's subcomponents. They can initiate upgrades of the service. They can start, stop or restart the service as needed. The service should expose configuration knobs so that the consumer can control the level of redundancy, user access, scaling parameters (auto scaling, infrastructure thresholds, etc), capacity and user access.

It can run anywhere - The service should be able to be deployed anywhere. In a public cloud or in your company's data center.

It is open - The source code of the software and the declarative definition of how the software is wrapped as a service should both be open sourced. This will give the the consumer of the service the control they desire.

How do we get to Open Sourced Services? 

The creators of open source software have not had an easy and unified way to package up their software in a way that meets the above criteria until recently. Thanks to the disruptive technology of containers, such as docker, and orchestration systems (such as kubernetes, swarm and mesosphere), I believe we now have a platform in which we can build our open sourced services on top of.

Note: I'll be using Docker and Kubernetes in the rest of this article but you should know that there are alternatives (swarm, mesospahre, rocket, oci, etc). 

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. If open source groups takes their code and packages it inside containers they will have the building blocks required for turning their software into a service (that can run anywhere).

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 helps groups deliver on the above characteristics for what makes up an open source service.

Creators of open source software now have a way to package their software up and deliver it as a service.  Sweet!!!! So, how would we consume these new services?

How will we consume open sourced 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 would need to choose and install some open source services . For example, let's say they want to use a noSQL service for their application. Previously, their choices where using something like AWS's DynamoDB (with AWS lock-in) or they could have engineered their our own Cassandra cluster with a bunch of blood and sweat. With open source services, all consumers will need to do is install the cassandra service on their kubernetes cluster of choice. They might do this with an easy command line tool ('kubernetes install service cassandra') or perhaps by logging into an app store and clicking on the cassandra service. Consumers will want to control the service by setting some parameters, like capacity limits and redundancy options, so that the service meets their needs. After that, the consumer simply starts using the service and keeps an eye on all the fun metrics and logs the service provides.

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

With open source services there are lots of winners: Developers will be able to build their applications the way they want to while getting the control they need. Tech execs get freedom from cloud lock-in and have a path to a true hybrid solution. Public cloud providers get to continue to sell infrastructure. Open source projects get a way to easily package their software as a service which increases their user's perceived value. Entrepreneur's get a brand new gold rush as their are plenty of challenges and opportunities.

Up next - Marriage #2 - Managed Anywhere Services

One of the down sides to open sourced services is that sometimes there is no one to call in case things go wrong. In my next post I'll write about an alternative approach that aims at solving that problem and opens up a new way for companies to make $$$ by delivering these services.

End

Thanks
Chris

--

Some useful links:

• Learn more about containers and kubernetes: http://kubernetes.io/v1.0/docs/whatisk8s.html
• A list of some early versions of open source software packaged up as services: https://github.com/kubernetes/kubernetes/tree/master/examples