We talked about the overall design of an online shopping store that can scale starting with our post here. Then we proceeded to discussing data infrastructure and data security in a system design case in previous posts. We started looking at a very specialized but increasingly popular analytics framework and Big Data to use with data sources. For example, Spark and Hadoop can be offered as a fully managed cloud offering. we continued looking at some more specialized infrastructure including dedicated private cloud. Then we added serverless computing to the mix. Today we continue the discussion.
The serverless architecture may be standalone or distributed. In both cases, it remains an event-action platform to execute code in response to events. In the latter case, it can be offered as a managed service on IBM Bluemix. The console to this service gives a preview of all the features on OpenWhisk. We can execute code written as functions in many different languages. The BlueMix takes care of launching the functions in its own container. Because this execution is asynchronous to the frontend and backend, they need not perform continuous polling which helps them be more scaleable and resilient. OpenWhisk introduces event programming model where the charges are only for what is used. Moreover it scales on a per-request basis. Together these three features of serverless deployment, granular pricing and scaling make OpenWhisk an appealing event driven framework. Even the programming model is improved. Developers only need to focus on Triggers, Rules and Actions. Invocations can be blocking, non-blocking and periodic, different languages are supported, and it allows parameter binding, chaining and debugging. Both the engine and the interface are open and implemented in scala. In fact, it is better than PaaS because not only the runtime but the deployment is managed too.
All requests pass through an API gateway because it facilitates security, control, mediation, parameter mapping, schema validation and supports different verbs. Routes and actions can both be defined. CLI, UI and API are also available
Internally OpenWhisk uses a database to store actions, parameters and targets. This database can be standalone or distributed and is usually couchdb or cloudant respectively.
It uses a Message Bus like to enable interactions between load balancers, activators and invokers. Activators process events produced by triggers. An activator can call all actions bound by a rule to a particular trigger. Invokers perform actions against a pool of containers. Actions are invoked on containers from a pool that are maintained warm.
#codingexercise
Reverse a linked list in O(1) storage
null
1
1-2
1-2-3
void Reverse(ref Node head)
{
Node current = head;
Node prev = null;
while (current)
{
var next = current.next;
current.next = prev;
prev = current;
current = next;
}
head = prev;
}
The serverless architecture may be standalone or distributed. In both cases, it remains an event-action platform to execute code in response to events. In the latter case, it can be offered as a managed service on IBM Bluemix. The console to this service gives a preview of all the features on OpenWhisk. We can execute code written as functions in many different languages. The BlueMix takes care of launching the functions in its own container. Because this execution is asynchronous to the frontend and backend, they need not perform continuous polling which helps them be more scaleable and resilient. OpenWhisk introduces event programming model where the charges are only for what is used. Moreover it scales on a per-request basis. Together these three features of serverless deployment, granular pricing and scaling make OpenWhisk an appealing event driven framework. Even the programming model is improved. Developers only need to focus on Triggers, Rules and Actions. Invocations can be blocking, non-blocking and periodic, different languages are supported, and it allows parameter binding, chaining and debugging. Both the engine and the interface are open and implemented in scala. In fact, it is better than PaaS because not only the runtime but the deployment is managed too.
All requests pass through an API gateway because it facilitates security, control, mediation, parameter mapping, schema validation and supports different verbs. Routes and actions can both be defined. CLI, UI and API are also available
Internally OpenWhisk uses a database to store actions, parameters and targets. This database can be standalone or distributed and is usually couchdb or cloudant respectively.
It uses a Message Bus like to enable interactions between load balancers, activators and invokers. Activators process events produced by triggers. An activator can call all actions bound by a rule to a particular trigger. Invokers perform actions against a pool of containers. Actions are invoked on containers from a pool that are maintained warm.
#codingexercise
Reverse a linked list in O(1) storage
null
1
1-2
1-2-3
void Reverse(ref Node head)
{
Node current = head;
Node prev = null;
while (current)
{
var next = current.next;
current.next = prev;
prev = current;
current = next;
}
head = prev;
}
No comments:
Post a Comment