Sunday, March 13, 2016

Machine Learning, Deep Learning and Streaming Data Processors

When AlphaGo beat the human last week using ML to process a small set of board positions which its computing power could process, it proved that Deep Learning ML (that which uses algorithms vs. simply data) has arrived. But can the same machine analyze a streaming set of unrelated mouse clicks to identify a "hack"? Could it have blocked the hacking of NY Fed and saved Bangladesh $100M of lost funds?

As I refresh my understanding of ML - this time with Spark MLLib. I am thinking that this use case of streaming data analyzes with ML or Deep Learning is the NBT (Next Big Thing). To run this type of computational jobs, one requires a cloud because no small cluster will do and it needs a special fabric of the network because nothing enforces better than a policy on the network. Next generation compute systems and specially memory/microprocessor arch has found its killer app in streaming data processing just like GPUs found video games. This time the games are played by hackers and loss is measured in hundreds of millions.  

Sunday, March 06, 2016

Microservices and Container - Not perfect together


There is a continuous turf battle going on since 1990s between developer and deployer (a.k.a Admin). Currently the admin controls the security, scale and size of the application. The developer controls the content, architecture and interfaces to other systems. Two new emerging technologies empower (or shift power) these two constituencies. Microservices empower the developer while container empowers the deployer/admin.

If either wants to take off, they need to find other partners not each other. If microservices want to take off it needs to get the container monkey off its back. It shifts the responsibility of security and scale on the developer and away from the deployer. Developer should ideally be limited to interface design and selection of abstractions that make logic easy to codify. If the security and scale fall in the hands of developer it is going against the grain of the evolution of application where binding is done as late as possible and certainly not at design time. A datacenter administrator will be very uneasy deploying applications where developer has coded in the security policy and scale limit.  

Container has a similar story. Container is not a disruptive technology like it is portrayed to be nor is its effect as tectonic as virtualization or  Java/JVM. It needs to find a partner in a deployment technology like a vagrant or rails or PaaS. Currently its main value proposition is the time to bring up a execution environment. But to get that one has to give up security, naming, directory and identity. In other words, what it is doing is pushing those decisions to the developer who is the most ill equipped to handle those.  

Tuesday, February 23, 2016

JESOA


In continuing my education on Microservices, I came across a blog which gave a formula for SOA. In essence the formula says remove ESB, SOAP, Persistence (Reliable Messaging) and centralized governance and add containers  + PaaS. That is the microservices definition.

There was a initiative a while back called JEOS for "Just enough Operating System". May be we should try that for Microservices equation as a function of SOA. It is just enough SOA.

Tuesday, February 16, 2016

Microsoervices

In trying to understand the difference between Microservices and Web Services (Circa 2002), I cam across this definition.

"..., the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." source: M Fowler


When web services started a similar definition was put forth. The main focus then was to get away from Java RMI into a light weight HTTP based communication and bring in language independence (then championed by Microsoft's CLR). As we implemented web services it became quite obvious that HTTP was quite heavy weight and language independence was not very economical. In fact what worked was language homogeneity with standardization on language that could shed weight for simple tasks and leverage a framework for heavy lifting. 

One of the biggest innovations in Java was the built in packaging and (later) deployment mechanisms. In fact most of the appeal of Java was in its "platform" features and not language features. This whole CNA biz smells a lot like language once again taking control of deployment and not leaving it to operations. We are seeing a application ops profession asserting itself. 

Sunday, September 13, 2015

IoT is a Cloud Network

Cloud Native, SDN and SOA are all techniques not technologies. IoT is not a technique it is a use case that needs to use the above mentioned techniques to enable a mesh of connections that is manageable, secure and most of all just works. IoT could use any infrastructure including the carrier network but it is most likely end up using the cloud as a IaaS. IoT is a cloud networking problem that needs some connectivity middleware to sit on top of a virtual network. IoT is an application designed using SOA that will provision its network using SDN and will use ephemeral compute threads that have preexisting binding to the language runtimes. 

Wednesday, July 08, 2015

sdn and CMS

Only a few years ago, datacenter architects picked their overlay tunnel technology and created a list of stacks with which to build out their datacenter network. The cloud management system or even "the cloud" was an after thought. Today the tables have turned. We have datacenter architects debating the merits of various CMSes like OpenStack, vVMware (vSphere, vCAC, NSX) and a very distant third or fifth CloudStack. Within their CMS they are asking for support from one or more SDN stacks. The days of stanalone SDN stacks are gone. The battle today is between an open ecosystem like OpenStack vs. multiple closed ecosystems.

So what are the SDN stacks being evaluated on by these cloud datacenters?

First is ability to scale. And by scale, I don't mean just the overcoming the vlan exhaustion issue with annoating BGP or encapsulating L2 in L3 etc. Scale means the performance of the cloud network scales with the number of nodes in the datacenter. The nodes are server nodes. The cloud network does not scale with number of switches. Scale means your automation system can manage the configuration of a 50 node cloud as easily as 5K node cloud.

Second is heterogeneity. This one is a quite a beast because it requires supporting all the major hypervisors, authentication systems, SIAMs,  best of breed appliance (virtual and physical). From a cloud vendor's perspective this is where the R&D dollars are mostly spent i.e. in creation of a heterogenous ecosystem. Not proprietary ones like iCloud.

Third is security. Not just network security, or long expensive compliance test but application data input validation, fraud prevention, almost waf like.


Monday, April 06, 2015

Killer App for Overlay Networking/SDN

SDN has been searching for a killer app since its birth in the midst of protocol and encapsulation debates of 2011. It wasn't monitoring, flow management or physical network orchestration for a controller. It turns out it is container networking.

Container is challenging the VM or a group of them is a unit of application. Its value proposition is removal of the virtualization tax and being open source it does not cost a whole lot to try out. The schedulers (k8, mesos etc.) seem to be maturing fast enough but the networking behind is still quite elementary.

Using offloads that accelerate encap/decap of an overlay network on the JEOS (Just enough OS), containers with virtual interfaces can outperform hypervisor based VMs and integrate better with orchestration technology like gubernetes.