Monday, March 28, 2016

The paradox of learning to build bombs.

Peter Thiel writes in his book From Zero to One,  chapter 14, page 173
OF THE SIX PEOPLE who started PayPal, four had built bombs in high school. Five were just 23 years old— or younger. Four of us had been born outside the United States. Three had escaped here from communist countries: Yu Pan from China, Luke Nosek from Poland, and Max Levchin from Soviet Ukraine. Building bombs was not what kids normally did in those countries at that time. 

The New York Times today writes:
Little is known about Khalid and Ibrahim el-Bakraoui, whom the authorities named on Wednesday as having been involved in the Brussels attacks the morning before. Ibrahim blew himself up at the city’s main airport, they said, and Khalid at a subway station. 

Unlike the founders of Pay Pal,  they build bombs and then they blew themselves up, almost simultaneously, with the only goal of killing as many innocent people as possible.
What turns people toward violence? ... Despite millions of dollars of government-sponsored research, and a much-publicized White House pledge to find answers, there is still nothing close to a consensus on why someone becomes a terrorist.
“After all this funding and this flurry of publications, with each new terrorist incident we realize that we are no closer to answering our original question about what leads people to turn to political violence,” Marc Sageman, a psychologist and a longtime government consultant, wrote in the journal Terrorism and Political Violence in 2014.
 Institutionalized rape, suicide bombers, decapitations, using dogs and autistic people as live bombs and other horror stories, can not be the source of the future

 All  un-natural demands, that go against the survivor instinct and family units, will fail.

Walter Isaacson, Steve Jobs biographer writes in his newer book The Innovators
“I always thought of myself as a humanities person as a kid, but I liked electronics,” Jobs told me when I embarked on his biography. The people who were comfortable at this humanities-technology intersection helped to create the human-machine symbiosis that is at the core of this story.
Few people know that Steve Jobs natural father,  Abdulfattah “John” Jandali, is born in Syria

Friday, March 18, 2016

AWS Lambda made a mistake

This is a Post Scriptum to the blog The Miracle of Apcera and AWS Lambda

Chad Lung AWS Lambda tutorial

Chad Lung is one of the gurus from EMC Cloud Services Group.  On January 12, 2016, he published a Lambda Tutorial Build a Python Microservice with Amazon Web Services Lambda & API Gateway

He wanted to show how simple is to build a microservice. Normally he uses Python 3.x, but AWS does not support it. So he used Python 2.7x.

My guess about 20% of the readers were coders. They probably said: "Wow" and and felt the urge to try themselves later duplicating the demo.

80% were people like me: no coders. We said; wow! this is from Amazon, then it must work, with so meany big names using already AWS . (Some people say the same about Google or Facebook or any other sacrosanct name)

The review ends
That’s it! Once you’ve worked through this a bit and play around its actually very easy to work with. 

 3 Reasons AWS Lambda Is Not Ready for Prime Time

This is the title of a blog from DataWire by @_flynn published less than a month later on February 9, 2016.
When we at Datawire tried to actually use Lambda for a real-world HTTP-based microservice shortly before Lung’s tutorial came out, though, we found some uncool things that make Lambda not yet ready for the world we live in:
  • Lambda is a building block, not a tool
  • Lambda is not well documented
  • Lambda is terrible at error handling
Lung skips these uncool things, which makes sense because they’d make the tutorial collapse under its own weight, but you can’t skip them if you want to work in the real world. 
You better to read the article. Yet see the amount of manual work you do with Lambda today
It’s not just Lambda, even: AWS’ model is that they provide building blocks, and they expect others to wrap real tools around them. If you try to interact directly with AWS, it’s absurdly manual.
To wit, Lung’s tutorial shows us that manually setting up a Python Lambda is a twenty step process – and that’s a service with exactly one endpoint that uses GET and takes just one argument on the query string. Mind you, about half those steps (8-10, depending) are things you’ll have to repeat for every endpoint you create. If you have even five services, you’re looking not at 20 steps, but 50-60. Imagine 100 services. Imagine how often you’ll have to do this if you’re using versioned endpoints. Does 8-10 manual configuration per endpoint, every time you roll out a new version, sound like fun?
The root of the problem here is that we want a tool (our microservice) but AWS gives us building blocks, and leaves connecting them up to us. 
Nice to know Amazon Web Services makes a boo-boo sometimes. AWS appears more human. The only problem is that their boo-boos are huge boo-boos, proportional to their reputation and size

The ATM machine in St. Petersburg, Russia 

In 1996, I was working for small banking software  company in Toronto, Canada. I went to Russia, St. Petersburg, to sell software for  ATM to a local bank 

At that time the only ATM was at  the central Post Office and they had no financial switching software or a network

Central Post Office San Petersburg< today
The ATM was operated by a bank employee sitting behind the wall, delivering the cash to the machine, who, in turn, delivered it to the customer through a slot.

Generating 100 microservices using 5,000 manual steps is somewhat similar to this ATM story. This is a boo-boo and AWS will fix it. Just don't take their words for granted.

Wednesday, March 16, 2016

The Miracle of Apcera and AWS Lambda

I am not a coder. But each time I come across other's wisdom and knowledge, I hold the power to set it free. As a blogger, I  tear off a chunk and give it away to the people in need just like me. I discovered a sort of miracle and I want to share it.

The first question is always Why?  People don't buy what you do, they buy why you do it.
Simon Sinek Golden Circle

Why AWS Compute Services?

AWS started with EC2;  you select a number of  virtual servers and run applications.  
In a client-server model, the server-side application is a monolith that handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database. 
The problem with a monolithic architecture, though, is that all change cycles usually end up being tied to one another.  A modification made to a small section of an application might require building and deploying an entirely new version.  If you need to scale specific functions of an application, you may have to scale the entire application instead of just the desired components.
ECS is Amazon Docker container management service. I have talked about it in Why Docker is a winner versus VMs

Why AWS Lambda?

Lambda AWS eliminates the old way of orchestrating workflows...
Slideware AWS
... and it replaces it  by a single function that takes care of everything
Slideware AWS
AWS Lambda is counter intuitive to those used with AWS EC2. There are no servers to provision or manage and you can  code for "virtually any type of application or back-end service - all with zero administration."

Amazon created a new pricing model, based on the number of requests for your Lambda functions and the time your code executes. The examples on the web site show reasonable costs, but the storage S3 and Dynamo costs are not included.

It makes auditing the costs of AWS services even harder then before.

Why AWS Lambda runs well microservices?

While there is no standard, formal definition of microservices, there are certain characteristics that help us identify the style.  Essentially, microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
The communication is essential. I heard that Lambda is like a modern throw back to Message Oriented Middleware (MOM). It abstracts out any transports and just has code fragments that respond to events/requests; This is very relevant to Microservices.
How the services communicate with each other depends on your application’s requirements, but many developers use HTTP/REST with JSON or Protobuf.  DevOps professionals are, of course, free to choose any communication protocol they deem suitable, but in most situations, REST (Representational State Transfer) is a useful integration method because of its comparatively lower complexity over other protocols.

My kitchen wall clock is atomic

In a very simple way, I experience a microservice in my kitchen. I have a $25 wall atomic clock, which changes for Daylight Saving Time  twice a year. I could have two monolith apps: one for summer and one for winter. Yet my clock receives a trigger from Boulder Colorado and uses one application only. The latest  NIST-F2 standard is accurate 1 second in 300 million years.

This type of time accuracy is probably important to know how long I should boil an egg :-)

On a more serious tone, here is a sample of the logic used before implementing a new microservice:
Imagine Company X with two teams: Support and Accounting.  Instinctively, we separate out the high risk activities; it’s only difficult deciding responsibilities like customer refunds.  Consider how we might answer questions like “Does the Accounting team have enough people to process both customer refunds and credits?” or “Wouldn’t it be a better outcome to have our Support people be able to apply credits and deal with frustrated customers?”  The answers get resolved by Company X’s new policy: Support can apply a credit, but Accounting has to process a refund to return money to a customer.  The roles and responsibilities in this interconnected system have been successfully split, while gaining customer satisfaction and minimizing risks.

Lambda versus Apcera

Apcera NATS is faster than Lambda based MOM

Apcera can do all what Lambda does,   It uses NATS messaging system. Here is why

Chart source:
The transport of NATS is interesting, but not important. It does mean that adding a new source event type is trivial, and that with NATS performance and scale come for free. As a developer you do not need to be worried about the transport.

Other significant differences

Apcera layer abstracts the infrastructure not only inside AWS. 
  1. Apcera will be multi-cloud, and can run on-premise as well as multiple cloud providers. Lambda is not
  2. Apcera can generate source events from anything you want, and process them anywhere you want. Lambda can only generate pieces of code for microservices
  3. Apcera can code the  policies for all AWS apps if the are linked to their platform (not only Lambda)
Everything else would be very similar.

Why not use Apcera to manage the Lambda function within AWS?

Good question. Apcera can run any app on any supported cloud with no modification.

As Apcera is the backbone of Ericsson's digital industrialization software stack, it can use Lambda to help AWS expand outside AWS customers traditional boundaries.

Apcera's real value proposition

Apcera creates an OSS (Open Source Software) Ecosystem,  true multi-cloud, with the ease to add new events to any system. (see the definition at the end)

AWS can use this platform to reach any datacenter outside Amazon circle of direct customers. It is the first step to create virtually a data center platform for the Earth planet and beyond

It is a miracle

AWS reputation in cloud plus Apcera can spawn a string of miracles that blend seamlessly into the order of things. They break no rules, but change everything.

The most awesome of miracle reveal the infinite possibilities within the finite nature of everyday things. Quoting the blogger Peter Linden from Ericsson:
The most exciting part of both the present and the future of data centers is the construction of distributed data centers. Data centers are being brought closer and closer to users to improve their user experience. ...Popping up in our urban neighborhoods like convenience stores, they will be designed to support the most frequently used digital services in our ’hoods as a start. Imagine a network end-point rolled into a neighborhood in a few freezer-sized cabinets, simple to place with easy access to power, cooling and connectivity.
Common sense is strengthened by joy. Just google to see who said these words two hundred years ago.


Here is the definition of an open source software ecosystem from a paper by Walt Scachi, from University of California at Irvine.

 What is open source?
● Open source software (OSS) denotes specifications, representations, socio-technical processes, and multi-party coordination mechanisms in human readable, computer processable formats.
● Socio-technical control of OSS is elastic, negotiated, and amenable to decentralization.
● OSS development subsidized by participants.
 What is a (software) ecosystem?
● An ecology of systems with diverse species juxtaposed in adaptive prey-predator food chain relationships.
● Economic network of processes that transform the flow of resources, enacted by actors in different roles, using tools, to produce products, services, or capabilities.
● Software supply network of component producers, system integrators, and consumers.

Sunday, March 06, 2016

What is NFV?

I did notice that most people, like me, who come from a grid and cloud IT universe as it was not even five years ago, like to think we know what NFV is.

Nati Shalom, CTO and founder of Gigaspaces is one of the top technical bloggers and entrepreneurs on the web. He is humble enough to write:
As with any new hype, the term NFV quickly became overloaded and confusing, so I thought it would be beneficial to try and clarify it a bit.
He has a unique perspective, so I decided to quote his entire blog from two years ago.

FEBRUARY 19, 2014

Blog Archive

About Me

My photo

AI and ML for Conversational Economy