Sunday, February 21, 2016

EAI for "AWS Enterprise"

Having worked almost all my career (so far) within enterprise application integration, could not help but to think about how various apps running within AWS could be integrated. One straight forward approach is to run the middleware solution within cloud such as Oracle SOA Fusion Middleware.

However, from the data integration point of view, IMO, AWS has already a solution in place ("loosely" speaking) in the form of AWS Lambda. So far with the support of Node.js and more specifically Java, it already "qualifies" for an integration tool. So far we know that Lambda can at least integrate the following (And this is far from complete):

1. S3: You put an object to a bucket and trigger Lambda function which can read the object and can work on the information within.
2. Dynamo DB: You can create stream on any table and trigger a lambda function.
3. SNS Notification: As an "Email" integrator.
4. API Gateway: Wrap your function as an HTTP service.
5. Scheduled trigger: Compared to an "Inbound Activation Spec" similar to a typical JCA inbound adapter.

And various others: Cloud Trail, Android, Custom App, VPC and continuing... Business logic in terms of routing and transformation will of course be custom and as part of Lambda will be highly scalable (Assuming written as such)

Best part of Lamda is its cost model, based on the number of requests. On top, you will not have a (usually) heavy weight app server or even any "server box", no OS level maintenance - No "Ops"!

Very eager to know how this Lambda evolve and gets adopted by enterprises.


Sunday, October 11, 2015

Go Build

"There is never a better time to build. So Go Build!" - Dr Vogels, re:Invent 2015.

One long year and this event has triggered me to blog a new post. Another reInvent and another bunch of service announcements. Although AWS enabled developers since its inception, the latest announcements in the last 2-3 years, indicate how its taking further steps to enable even more agile enterprise. Some of them are:

  1. AWS Mobile Hub: Does some of the mundane tasks for developers, like image/artefacts storage from mobile to cloud, user login, analytics etc. Its like: "coding as a service" if you may. Developers just need to write the "core logic". Interesting to see how the boundary of "core logic" has become so concentrated towards just writing "custom" business logic. 
  2. AWS IoT: Complete back end environment for the device sensors. You are few clicks away from configuring the rules based on the stream of information received from sensors. 
  3. AWS Lambda: Its an amazing offering. Gone are the days where you need to launch EC2 instances, within auto-scaling group specially for small / medium level functionality. Now, you write lambda functions for the same purpose and "trigger" them. As long as the function "runs", you are charged and not when it doesnt run. So there is no "running cost" as it used to be with EC2. 
Many others such as X1 instance, ECS, analytics services, Firehose, RDS with MariaDB, Aurora, Inspector that I did not get a chance to play around with. But one thing for sure is that AWS is rapidly expanding with not only IaaS but also application services with its own SQL and NoSQL servers. Interesting to see whats up in the next 5 years. It would not surprise me if they launch smart, self-learning application services competing with other established players in the market. 

Wednesday, October 15, 2014

Morris Magic

While preparing for tech companies, I have had a lot much insights into the computer science and boy, aint I get bamboozled!! Already I find trees and graphs one of the challenging area, given that I need to think about these problems both from iterative and recursive ways to solve problems just in case interviewer asks me....

Recently I came across a question that asked for NO recursion, NO stack usage to visit the tree INLINE! I was stumped. It was the I tried drawing 2 pages and gave up on algo. It was pretty cool solution at the end as I figured from the solution. Mr Morris came up with the idea of changing the whole tree pointers while traversing one node after the other. Then visit and then change the pointers back as though nothing had happened.

Implementation in Java:

public void inLineMorrisIterative(BTreeNode node) {
if (node == null)
return;

while (node != null) {
// Go to the far left of this node
if (node.left == null) {
// Visit this node
visit(node);
// Go right
node = node.right;
} else {
// There is a left subtree
BTreeNode tmp = node.left;
// Get hold of the right most until it reaches extreme right or
// pick up its child which is also its parent
while (tmp.right != null && tmp.right != node) {
tmp = tmp.right;
}
if (tmp.right == null) {// If rightmost
tmp.right = node; // link it to the node.
node = node.left; // Get the node to the root of the left
// subtree
} else { // We get to the parent of tmp
// Visit the node then
visit(node);
// Break the temporary link
tmp.right = null;
// Move right
node = node.right;
}
}
}
}

Saturday, August 16, 2014

"SOA Developer" - Really?

I have been looking at some of the developer related job ads and many a time I come across a job with title "SOA Developer". I cannot understand this really. Within the description it specifies a particular tool/technologies such as Oracle SOA Suite.

As I understand, SOA is an architecture not a language or framework or anything much technical. If the employer mean "SOA architect" by the title "SOA developer", I do not have problem with that because architecture in SOA should be "developed" by an architect.

So whats the real position should sound like. May be "Service developer" but that will be too abstract. So, it boils down to "orthodox" - BPEL developer or Java developer. I guess, because of so much hype about SOA, it has turned into business of selling product in the name of "architecture" and nothing is achieved by organization except for pain in terms of money and effort to look for tool specialists, pay hefty licence and build (Mostly un-scalable) infrastructure in order to run the tool.

If there is any title begins with SOA, in my view, the next word should be either "Administrator" or "Architect" just to be clear. Once the architecture is done, then a tool should be selected to implement the services or to wrap the legacy application with service layers. Then and only then there will be a need for a developer/coder to build the service. But most of the time, organization has already invested in one technology, say dot net or Java, so it does not harm to have "Java developer" or ".NET developer" from the inception of a SOA project but the job title should state exactly that and not "SOA developer".

Monday, July 7, 2014

Application Development Trend

Recently I have been trying to venture into some of the popular tools and technologies which I did not have much idea about. After working through the cloud, one thing I figured out is that developers have got independence from any infrastructure and its administrative need. They not only can concentrate on their app development but also learn bits and pieces (Specially basics) on networking and OS. On top of this, given that some offer free tier access, no drama in experimenting on a new piece of software service or even put something in production.

Recently, I started getting my hands dirty on document based NoSQL and it suddenly occurred to me that application developers are now almost free of database development dependencies as well, well ofcourse only if the problem can be solved by non-relational database. So, no headache on schema design then ripple effect from the changes, dependencies on the DB development, etc. There is, nonetheless, administrative work involved.

Here is my conclusion - Application developers really really need to design and develop their application very carefully with -
1. ALL business requirements fulfilled.
2. Non-functional requirements such as improved performance with proper use of algorithm.
3. Scalable applications development with appropriate usage of data structure.

This is a good opportunity for app developer to learn to develop some really good programming habit as these (and many other) tools are providing them with pretty much complete independence.

I am looking forward to getting opinions on this trend for I guess being application developer myself, I may be a little biased.

Wednesday, November 20, 2013

Barriers or excuses for not moving to cloud

Since the time I have been going hard on learning and experimenting the cloud computing with the leading IaaS provider - AWS - I have always been thinking what stops CIOs from moving to the cloud. In the due course of reading papers, talking to people, I got some points what they call barriers:


  • Performance and scalability - If a CIO thinks that one cannot move to cloud and be as scalable and high performing, I have to say that he/she needs to be educated on some of the fundamentals on cloud computing. Auto-scaling (Up and Down) automatically - THE biggest asset! How can someone prefer leaving their infrastructure idle or shutting down services to provide more server resources in case the demand peaks to take the Autoscaling opportunity provided by cloud providers such as AWS?? Scientific researchers, NASA live telecast from MARS Rover, banking industries, blue chips companies - please - they all are in cloud albeit hybrid model but they are and dont say that their cloud infrastructure is not performing as good. 
  • Infrastructure "Type" - Really?? At the end of the day do you want "T5", IBM XIV, Solaris BLADE, etc etc or you are looking for the same PERFORMANCE?? Are you really looking for managing those infrastructure no matter how many times you have to have the outages or do you want highly scalable, available and durable infrastructure with bare minimum utility based costing model - NO MATTER WHETHER THEY RUN YOUR SERVICES ON CHEAP INFRASTRUCTURE! Do you really care??
  • Security - Funny! Its one of the MAIN reasons moving to the cloud. The level of security AWS can provide, pretty much impossible to achieve unless you move away from your CORE business which may be selling a product and just manage secure infrastructure :) Please read 100s of pages from AWS Security White Paper - Each and Every service is SECURE - aside from app level and firewall rules level security that the coimpanies will provide on top! 

From what I can understand, companies will gradually move away from on-premise infrastrucure ONLY when they will see their competitors gaining extra-ordinary advantage all of a sudden, but Alas! it might already have been late move from them. The whole idea is NOT TO WORRY ABOUT your infrastrcture - that takes MOST of your IT time, resources and money and FOCUS on your CORE business, develop new services, products, deploy them within seconds for your customers, add more agility in your IT environment. Make your infrastrucure more secure, scalable, available with multi zone DR planning already in place within minutes if not seconds. Compare this with on-premise infrastructure maintainance - Dealing with vendors, upgrading Oracle, paying millions (Even for idle infrastructure), waiting for approval - rings a bell??

Welcome to my blogs

The contents here are my independent point of view. They reflect my thoughts, experience in my professional and social life.

Search This Blog