Microservices, history iterates, etc

It was in an episode of #rebuildfm where I heard the term microservices for the first time. It sounded nothing new to me, but it’s among the latest buzzwords.

I started my carrier as an instructor/conference speaker at around 1995. Windows NT 3.51 finally made threads available to COM based applications through it’s intrduction of MTA (multi-threaded apartment). COM or Component Object Model was a technology that enabled inter-application communication through OLE2 (Object Linking and Embeddding). OLE(1) enabled an Excel speadsheet be embedded in an Word document. OLE2 made a step further and made the underlying technology available to 3rd party developers through COM. In other words, it was unix pipe for a Windows GUI application. Inter-process communication took place on top of COM’s intra-process, inter-thread communication.

With Windows NT 4 in 1996, Microsoft took a step even further and introduced DCOM, or Distributed COM. By 1996 with help by popularity of Windows 95, corporate intra-network became pretty popular. Client-Server system. Visual Basic application connected to Oracle 6 database. 3-tier, Windows DNA. Inter-machine communication took place. DCOM tried to solve the problem around programs communicates over machine boundary by leveraging COM inter-process communication.

It allowed programmers feel as if they were writing code that communicated with other COM interfaces over process boundary, even when they were writing code that actually communicated over machine boundary, over corporate, 100Base-T LAN.

DCOM even introduced DCOM over HTTP later so COM interfaces can be exposed over the Internet.

J2EE/EJB, CORBA, the same story, different companies involved.

SOAP, or Simple Object Access Protocol, was born to make inter-machine communication over HTTP a reality. RPC can be replaced with HTTP protocol. Network data representation (NDR) can be replaced with an XML document. But SOAP is still a protocol for Object-RPC systems. It had been so until SOAP version 1.2. It was a tragedy for SOAP that SOAP v1.1 became too popular. Most dummy implementations of it naively believe RPC calls should look the same to programmers regardless of how long “the wire” was. SOAP 1.2 is a messaging protocol. It specifies a message format in XML Infoset which aimed to create an abstraction layer on top of XML document which is defined as text.

SOAP 1.2 defines headers and bodies and processing models; it looks very much like what HTTP is being used today. SOAP 1.2 was intended to use more transfer protocols than just HTTP because HTTP was text based and thought to be slow; SOAP over SMTP could also be possible; SOAP could also be used even in-process communication (XML Infoset can be serialized to a binary format). It was too late; when Microsoft introduced .NET Framework, even most product managers in Microsoft still saw SOAP to see objects, at the time .NET objects written in C#. WSDL does have a way to define document oriented interface as well as legacy, rpc oriented interface. Document oriented interface never became popular. “Wise” brains started to criticize how stupid the idea was to event think about doing RPC over the wire. Coarse-grained messages. Messages, not method calls. Services not objects. Service oriented architecture.

It was interesting few months of my carrier during these days, because I was also able to see that there was the other side of the world. Blue pill? Red pill?

In the other side of thew world, Movable Type made trackback familiar. Dave Winer advocates RSS 0.91 and 2.0. RSS reader applications. NOKIA lifeblog protocol that can post an entry to TypePad from your cellphone.

These are based on this simple notion - sending an XML document over HTTP (be it GET or POST), is very usable for inter-process communication, without a concrete specification on which all tech giants agree. View source. Blog hacks. (I feel funny that Fiddler the sniffer became very popular these days. It was during these days I first used Fiddler and loved it until I switched to Mac.)

And Google Maps. Ajax is not very much a “protocol” but more like a good old client-server communication. Its JavaScript calls fine grained methods. Google servers are fast enough to process that many number of method calls fast.

There was this buzzword - SOA during the timeframe around my carrier. In SOA, all participating endpoints agree not only on a protocol and a processing model, but they also agree on a very concrete “business process document schema”, at least in their ideal world. RosettaNet, BPEL, BizTalk.

On the other side though, Ajax exploded. RPC between JavaScript on a browser and an HTTP endpoint got popular among programmers once again. It does feel easier to architect coarse grained message with these important idea of “connections can be lost; messages can be half-broken, etc, etc”. All you do is call a simple method like “add(1, 2)” and get “3” as a result. Programmers love it. RPC is easier than Messaging.

It was SOA and this idea of “all parties agree on an XML schema” that finished me in that part of the world. It was a ridiculous idea to me given trackbacks and RSS were already working in practice out there.

I joined Amazon as a technical evangelist, to adovoate to programmers. that this part of the world was more fun. I wrote magazine articles about it. I talked about it at some tech conferences. I let other programmers know how fun it would be to write code that does internetwork communication through “API” until I realized it would be fun for me too. I stopped talking and started writing code at Six Apart.

Fast forward a few years, I am still writing code that is getting large codebase. Some parts in my code communicate inside the system itself, but over HTTP. I heard the word microservices. Where limited number of coarse grained messages are transferred between services in a system. Wait, is this deja vu?

No, I guess not, partly because it is still about a monolithic system (if you can call “Amazon.com” a monolithic system). It is not about Amazon.com communicates with Google.com (which was what SOA circa 2005 was trying to accomplish). Also everybody in this generation understands that calling an endpoint over HTTP is way more expensive than calling a method inside a process. C10K problems.

Well defined interface, but the parties who must agree on that interfaces are still within a firewall. History doesn’t just repeat; it iterates like it draws a spiral.

I do feel sad when this generation points fingers at and laughs at SOAP/WSDL though. It surely served my carrier. I even feel grateful to Microsoft to adapt to SOAP, for if it were not them, I wasn’t aware of those XML related stuff until a few years later, which should have made my carrier very different.

By the way, COM taught me this thing called interface based programming too. COM interfaces have functions but not data. COM is not OO - you start by writing an interface definition by this language called IDL. Doesn’t it sound familiar?