<acronym id="60qqi"></acronym>
Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts

Thursday, February 23, 2012

Simple Workflow Service - Amazon Adding One Enterprise Brick At Time

Yesterday, Amazon announced a new orchestration service called Simple Workflow Service. I would encourage you to read the announcement on  where he explains the need, rationale, and architecture. The people I spoke to had mixed reactions. One set of people described this as a great idea and were excited that the developers can now focus on writing domain-specific code as opposed to writing plumbing code to orchestrate their actual code. The other set of people felt that this service creates a new cloud lock-in making it difficult for the developers to switch from one cloud to another as well as being able to interoperate at the orchestration level.

I believe this is a brilliant idea for a variety of reasons. Orchestration has always been painful. Ask the developers who have been involved in managing task execution across a cluster that required them to code for load balancing, handling exceptions, restarting hung processes, tracking progress etc. This is not a core competency the most developers have but they do end up writing such code due to lack of better alternative. The frameworks such as WS-BPEL were not designed to run in cloud-like environments and there has been no single standard REST orchestration framework out there that people could use.

From a vendor's perspective, I admire Amazon's ability to keep innovating via such services that differentiate them as a leading cloud vendor. As computing becomes more and more commodity, competing based on price alone isn't a good idea. If you're a cloud vendor you need to go above and beyond the traditional IaaS attributes even though you excel in all of them. I also see PaaS eventually bleeding into IaaS as IaaS continues to become a commodity. As far as PaaS goes, federated or otherwise, we're barely scratching the surface.

I don't see this service as a cloud lock-in but it certainly makes EC2 more attractive and sticky. I would be concerned if Amazon were to force the developers to use their SWS for orchestration. This is their version of how they think orchestration should be done and the developers can opt in if they want. And kudos to them to think beyond their cloud. The folks who worry about cloud lock-ins also talk about Amazon not following the standards. I believe that we should not create standards for the sake of creating standards. I am a believer in first showing that something works and later, if there's enough interest, figure out a way to standardize it. All these talks about standard-first even before you write that first line of code doesn't make any sense.

It's yet to be seen how this service turns out, but this is a huge step forward for getting more enterprise software customers onboard. Orchestration is one of the most chronic problems of enterprise software and with the challenges of a hybrid landscape to be able to orchestrate across on-premise and cloud-based solutions, this service is certainly a step in the right direction. Right Scale has been using a Ruby workflow
Ruote for their workflow needs and now they orchestrate these workflows using SWS  to achieve fault tolerance and concurrency. As you can see, Amazon has opened up a gold mine for start-ups. The back-end execution has always been challenging. Now, there is an opportunity to write your own enterprise grade workflow engine or scheduler that runs in the cloud.

Thursday, August 27, 2009

SOAP may finally REST

Lately I have observed significant movement in two transformational trends - adoption of REST over SOAP and proliferation of non-relational persistence options. These two trends complement each other and they are likely to cause disruption sooner than later.

The enterprise software that required complex transactions, monitoring, and orchestration capabilities relied on the SOAP-based architecture and standards to realize their SOA efforts. The consumer web on the other side raced towards embracing RESTful interfaces since they were simple to set up and consume. There are arguments on both the sides. However, lately the market forces have taken the side of REST even if REST has significant drawbacks in the areas such as security and transactions. This once again proves that a simple and good enough approach that conforms to loose contracts outweighs a complex solution that complies to stricter standards even if it means compromising certain critical features. The web is essentially an unreliable stateless medium and any attempts to regulate it is less likely to work in our favor.

Many argue that the self-describing standards for SOAP are its strength over the RESTful services that lacks such features. However designing a RESTful service is fairly trivial since it allows to learn and experiment by being iterative unlike a relatively complex upfront learning process associated with the SOAP-based architecture. There has been a flurry of activities in the messaging middleware by Google that makes these RESTful interface even more compelling. This includes Google Wave Federation and PubSubHubbub. The developers are more likely to prefer these messaging protocols against SOAP and that would mean more RESTful APIs in the Pushbutton Web. Easy consumability reduces the initial adoption barrier and that's the key to success in many cases.

Since I last blogged about the continuum of the database on the cloud from schemaless to full-schema new persistence options have emerged such as RethinkDB and HadoopDB and many debates have spurred questioning the legacy of the RDBMS. For a cloud-like environment the statelessness, ad hoc persistence design, and instantaneous horizontal scale go well with the RESTful architecture. The growing popularity of SimpleDB and CouchDB along with many discussions on how to achieve CRUD with REST signal that the persistence is becoming more RESTful and schemaless.

I was convinced quite some back that REST was certainly the future for the consumer web but the latest trends have made me believe that the REST will see its adoption in the enterprise software accelerated much sooner than I had originally expected. This is like Java and Internet; the organizations embraced Java and the Internet at the same. The same will be true for the cloud and REST. When the companies consider moving to the cloud they will reconsider their SOA and persistence strategy and will likely adopt REST and alternate persistence models.

The cloud might be the last nail in the SOAP coffin.

Saturday, August 11, 2007

SOA Security – A crystal ball?

Well, I hope not. The enterprise architecture should always consider the security aspects of various systems – authentication, authorization, audit trail, and non-repudiation. These fundamentals do not change when extended to SOA. Any SOA implementation should address these concerns. As this article suggests, there are multiple competing standards when it comes to SOA security and I personally believe that it is a good thing (at least in the beginning). Competition keeps vendors on their toes to follow a standard that works well and satisfies customers' needs. Loose consensus over rigid agreement works well for standards. CORBA is a good example of that. It took a lot of people many years to come up with this bloated standard and eventually what people got as a standard was a superset of all the possible features that addressed all the OMG members' needs and satisfied their egos. The end result was a comprehensive but useless standard.

In the SOA security world, there are competing standards, but they do not compete at the same level. If you are using WS-Federation, you can still use SAML tokens and if you are using SAML you can still use Liberty Alliance standards. All these standards will evolve and eventually the one that works well, and easy to use will win. I understand that organizations have concerns over investing too much into single identity management standard, but that does not justify organizations not investing into any security standards at all.

The companies are hard-pressed to open up their services to their partners to stay relevant in this competitive market. Don't listen to your IT department if they use the security card to scare you on your SOA efforts, instead work with them and prototype few simple ad-hoc federation solutions before venturing full-throttle into hub-and-spoke or complete identity federation solutions. This is similar to a kid learning how to bike. Use the training wheels, get rid of your fear, and once you understand how security works, get rid of the training wheels and go for a full-fledged solution. SOA security should not be a crystal ball; do your homework, follow your SOA governance and decision making framework, and most importantly have faith in your decisions – you will be fine.

Tuesday, July 24, 2007

Open standards and closed code

IBM is opening up a small part of it's patent portfolio to drive SOA adoption. The article has a quote - "This is telling people go for it and code using these open standards,". What exactly is open here? If it is open, why does IBM have patents on it? I haven't seen the patents here (you know the lawyers actually ask you not to do a patent search!) but it rather seems odd that you have patents on open standards that you make it available to the developers and actually get credit for them. The article also says - "I'm not sure how much developers worry about this stuff anyway," - right on. This is absolutely true. This is a pure PR play and demonstrates some of the issues with our current patent system and the patent stockpiling tactics that organizations employ. The actual impact of the patents to SOA adoption in general is questionable.

Tuesday, July 3, 2007

SOA ROI - interoperability and integration

If you are a SOA enabled enterprise application vendor trying to sell SOA to your customers you quickly realize that very few customers are interested in buying SOA by itself. Many customers believe SOA investment to be a non-differential one and they compare that with compliance – you have to have it and there is no direct ROI. A vendor can offer ROI if the vendor has the right integration and interoperability strategy. For customers it is all about lowering the TCO of the overall IT investment and not about looking at TCO of individual applications. SOA enabled applications with standardized, flexible, and interoperable interfaces work towards the lower TCO and provide customers sustainable competitive advantage. Generally speaking customers are not interested in the "integration governance" of the application provider as long as the applications are integrated out-of-the-box and has necessary services to support inbound and outbound integration with customer's other software to support customer's vision of true enterprise SOA.

It has always been a long debate what is a good integration strategy for SOA enabled products. Organizations debate on whether to use the same service interfaces for inter-application and intra-application integrations. Intra-application integration have major challenges, especially for large organizations. Different stakeholders and owners need to work together to make sure that the applications are integrated out-of-the-box. It sounds obvious but it is not quite easy. In most cases it is a trade off between to be able to "eat your own dog food" by using the published interfaces versus optimizing performance by compromising the abstraction by having a different contract than inter-application integration. There are few hybrid approaches as well that fall between these two alternatives, but it is always a difficult choice. Most of the customers do not pay too much attention to the intra-application strategy, but it is still in the best interest of a vendor to promote, practice, and advocate service-based composition against ad-hoc integration. There are many ways to fine tune the runtime performance if at all this approach results into performance degradation.

The other critical factor for ROI is the interoperability. The internal service enablement doesn't necessarily have to be implemented as web services, but there is a lot of value in providing the standardized service endpoints that are essentially web services that have published WSDL and WS-I profile compliance. The interoperability helps customer with their integration efforts and establish trust and credibility into the vendor's offerings. I have also seen customers associating interoperability with transparency. Not all the standards have matured in the area of Web Services and that makes it difficult for a vendor to comply to or to follow a certain set of standards, but at the minimum vendors can decide to follow the best practices and the standards that have matured.

Sunday, June 17, 2007

SOA Governance - strategic or tactical?

It is both. SOA governance is not much different than any other kind of governance in an organization. Successful SOA governance cannot be achieved without people framework. Socioeconomic factors such as organizational dynamics (I think it is a good synonym for politics) drive the SOA strategy for an organization.This is especially true for IT organizations where the organizations are on the supply side of SOA for their product offerings. Many people miss the fact that the governance efforts are not only limited to the internal employees in an organization but are typically extended to customers and partners. Many organizations co-innovate with customers and partners and these partners and customers significantly influence the SOA governance policies of an organization.

Many architects view SOA governance as a technical challenge, but I beg to defer. Strategic SOA governance is not just a technical problem; it is a business and process problem that has socioeconomic implications. I already talked about the people part. Talking about SOA economics, there is no good way to calculate ROI based on just SOA. Few people have actually tried doing this and I am not sure if this is a right model. Number of services or number of reusable services or any other QoS for SOA don't help to build an economic metrics. SOA is quite intertwined with the business and it is your guess versus mine in extracting a monetary value out of it. Having said this, people do work hard on making a business case for their organizations since SOA is hard to sell.

The strategic to tactical transformation of SOA is not easy. This is where people argue on several reference architectures, policies etc. These are very time consuming and dirty efforts and include several technical, domain, and functional discussions. Cross-functional team works well to tackle this kind of governance problem since it is critical to have a holistic (horizontal) view of SOA with enough help from the experts in several (vertical) areas. SOA architects have to have good people and project management skills since as I already mentioned governance is not just a technical problem. If you are a technical architect, you end up with a diagram like this. This diagram does not help anyone since it mixes a lot of low level details with high level details and the information is difficult to consume. Communicating the architecture is one of the difficult challenges for an architect and it even becomes more difficult if you are describing strategic SOA governance.

Sunday, May 13, 2007

Hello World from JavaOne 2007!

Just came back from JavaOne 2007. The experience was as good as I expected it to be, well sort of. The energy and excitement have been going down at JavaOne year after year. This is my seventh JavaOne and I could feel that. Not to sure what to make out that but there are a lot of missed opportunities on Sun's side. On a positive side the sessions were good and the live demos did work! As promised Sun announced the OpenJDK with GPLv2 license. Finally the open source community will get their hands around Java. Sun is going to maintain the commercial (and free) version of JDK and that should allow organizations to continue embedding it without worrying about any GPL issues around derivative work. I attended a session by Eben Moglen and he was quite pleased with this announcement. He was also optimistic that GPLv3 will be aligned with Apache license when it is finalized. I really hope that happens.

Apparently it was a crime if speakers did not to talk about Ajax. The Ajax discussion was hot last year but this year it was almost mandatory for all the sessions. SOA was not a big hit this year. I liked Sun's approach in embracing the popularity of dynamic languages and scripting. Instead of inventing something on their own, Sun pushed jMaki as a solution that wraps all the popular widgets and provides nice abstraction, compatibility, and inter-widget communication. The solution fits well with JSF. It was clear that I am not the only one who hated JSR 167. A couple of speakers expressed their frustration around JSR 167 and hoped that JSR 286 would solve some of these problems. The "convention was over configuration" was a popular message. It took these many years for the vendors to figure out that developers want something up and running when they install a toolkit. They don't want to go through configuration hell just to get few simple things done. Grails and Seam are good examples on "we get it". There were quite a few developers at JavaOne who also coded in .NET and PHP. Zend had a session and they demoed PHP to Java integration. There was a session on .NET interoperability as well. Sun pushed JSF as a flexible yet powerful application development framework. Since JSF is now officially part of J2EE, I hope it gets more tooling support, scalable runtime, and open source faces.
<acronym id="60qqi"></acronym>