One of the toughest battles I face these days is tying to make people understand that the “cloud” is more than just infrastructure. Modern cloud providers such as Amazon and Microsoft offer a development ecosystem. I think that this is such an important point that I want to state it again. The modern cloud is more than just server virtualization, it’s a full development ecosphere.
Now I’ve used two different terms here that are similar but distinctive. ecosystem and ecosphere. I want to describe what I mean by both. The cloud as a development ecosystem implies a set of open tools that can be used to develop solutions that extend beyond the cloud, while a development ecosphere brings to mind a closed system where a solution never leaves the cloud. Modern platforms provide both options. Large corporations can use the cloud as an extension of traditional data centers, and can and should look at using more than one provider. The ecosystem is typically associated to companies who are migrating to the cloud platforms. Companies who utilize the cloud as an ecosphere are more likely to be start-ups or smaller companies. Typically referred to as being “born in the cloud,” these companies might not have any server infrastructure outside of a cloud provider at all. Email, collaboration, and even the products they sell are fully serviced and sourced in the cloud.
What do these two sibling terms have in common? They both utilize more than just infrastructure. Data storage, messaging, file storage, security, work-flow, etc. These types of managed services that can go way beyond simple virtual servers, are what I’m referring to with both of the aforementioned terms Ecosystem and Ecosphere. Developers have an unprecedented ability to get to market with new software faster than ever before. This can be both empowering and frightening at the same time.
Month: November 2014
Fact Checking
I’ve been interested in the concepts of event sourcing for several years, and am taking a serious look at it again. I’m frankly a bit dismayed at what I’m seeing on google. On the first results page I’ve found a blog post that refers to event sourcing, and misuses the term. I’m hoping that there’s a translation issue here, as it’s a very well put together post. I suspect French may be the writers primary language. I also don’t have any fundamental issues with the architecture they describe in the post. I’m currently using something very similar, but it isn’t “event sourcing,” it’s Pub-Sub. While you are “Sourcing” events to a subscriber, this has nothing to do with event sourcing, and is already a well established messaging pattern.
We all misuse terms from time to time (I’m a big offender), and as our industry is constantly evolving it can be difficult to keep up with every new term out there. However; if you are going to use a term such as event sourcing in the title of a public post, please do just a bit of research before publishing. A quick internet search would have not only shown the mistake, but also introduced them to a new architectural pattern. I’m not trying to trash the author, hence I am not including a link. Rather I’m speaking of it here, more as a way to keep my self honest. As I said, I’m a big offender.
For those who don’t know what I’m going on about, event sourcing stores system data as a series of events in the order they occurred. While in some cases an aggregate object is created from these events, the events themselves are always maintained in an event store. Aggregate objects can be destroyed and then recreated by reading, or playing forward, the events in the event store. This allows you to recreate an object as it was at any period in it’s lifetime. The basic concept is similar to a source control system, where you can see the entire history of a files check-ins, and revert back to a specific period in time. Event sourcing is closely related to Domain Driven Design (DDD), and you will likely hear people refer to using the events to derive system state, as opposed to a specific objects data model.
The Architecture Journey – Micro Services
The term “micro-services” seems to be everywhere these days. As I’ve been looking into it deeper, my initial impression of it has changed. Mostly because my first introduction was from someone who knew even less than I did. This caused me to dismiss it originally. My mistake. As I’m learning more, it seems to be a natural extension of some principals I’ve always been a big proponent of, such as CQRS. While not the same, it does follow the principal of breaking up monolithic back ends into smaller units that can be scaled independently.
This is a very vague and generic description, but I’m really just beginning the journey. So far micro-services seem to be closely related to the direction I’ve been pushing my architectures over the last few years. I’m hoping I can leapfrog my own thinking on the topic, and evolve at a faster pace. Exciting times. I’ll post more on the subject as I learn, and have a chance to experiment.
PS: It’s NaBloPoMo time (National Blog Posting Month). I was very unsuccessful the last time I tried to do this. Lets see if I do better this time around.
Malignant Genius 