Emerging design 101

Emerging design 101

I strongly believe in emerging design & evolutionary architecture. I've seen too much in my life ;> to believe in up-front design & beautiful pictures turning miraculously into flawless, working systems. I'll save you detailed reasoning as I've written about that on several occasions already in the past. Let's consider the emerging design instead, because I've seen many people struggling with the idea which seems so easy at the first glance: how to make it work? what are the pre-requisites? what should be avoided? Contrary to the common belief, emerging design is not about taking it easy or going with…

Read More

Sensational comeback of stateful services

Sensational comeback of stateful services

There's nothing permanent in software engineering. Consider building services for Internet applications - for the last few years service design principles were quite straightforward: stateless >>> stateful sticky session (& session affinity) are made of suck if you really, really need session, at least make it immutable build a dedicated service layer, but make it as lightweight as possible & keep the state in separate persistent storage If you think about it for a while, it all made sense (still makes!), but ... there's a new Holy Grail bursting in popularity these days (however, to do justice I have…

Read More

Are you hedging your tech stack?

Are you hedging your tech stack?

Few weeks ago I've noted down an interesting notion that someone has mentioned during one of the discussions I've participated in: hedging technology The overall idea is simple, you may recognize it from hedging funds or hedging bets. Hedging technology is expanding your area of expertise in a particular field by learning another technology that basically applies to (/enables) the same scenarios as your primary choice tech (in that field), but significantly differs in terms of technical foundations: has completely different base dependencies (e.g.: platform, OS) utilizes different skillset(s) (e.g.: language) sometimes even represents completely different approach…

Read More

Proudly breaking things since 2001

Proudly breaking things since 2001

The Formula IMHO tech skills are 10% talent + 20% engineering common-sense + 20% theoretical knowledge + 50% practical experience. If I've under-estimated any of these, it's most likely (still) the practical experience. Needless to say - it's not ANY practical experience. Going through tutorials on every possible topic is still something, but to actually learn & improve, you have to challenge yourself: to learn something new on regular basis ... solve more & more difficult problems ... keeping in mind that difficulty has different aspects & dimensions (scalability, performance, maintainability, versatility, ...) Learning all this on your own may be fun, but ... learning scales well…

Read More

Distributed responsibility for Architecture - is it even possible?

Distributed responsibility for Architecture - is it even possible?

I've encountered a very similar situation in so many companies: their IT landscape grew all the time (while nothing was decommissioned), layers they've initially got became more complicated or even split into sub-layers: sometimes parallel, sometimes stacked. Obviously, different components frequently utilize different technologies, so the skill-set required to develop & maintain all that got significantly broader. Consequences are numerous: architecture is complex & hard to govern (kept consistent, maintainable and manageable) developing a single, meaningful, end-to-end scenario requires a spike through many layers - various skills & some coordination are needed IT managers are usually far more afraid of…

Read More

IODA Architecture - naming actual problem with Microservices

IODA Architecture - naming actual problem with Microservices

Few days ago I've run into this article on InfoQ: http://www.infoq.com/news/2015/05/ioda-architecture I found it amusing enough to dive deeper here (link taken from the article): http://geekswithblogs.net/theArchitectsNapkin/archive/2015/04/29/the-ioda-architecture.aspx I won't keep you guessing any longer - my amusement isn't about the overall idea of IODA or this horizontal to vertical (or the other way) thingie - IMHO the best thing about IODA is that it very clearly addresses the problem of (micro)service integration & dependencies between (micro)services. This particular topic is usually (in books,…

Read More

Micro-service ain't a micro-app

Micro-service ain't a micro-app

The concept of Microservices, even if a bit ephemeral, gets a lot of love nowadays. Reasons are quite straightforward, so I'm not going through that once again - what bothers me is some kind of misconception / overinterpretation I've already encountered few times. Microservices (MS): YES, encapsulate service business logic for coherent & compact slice of (sub-)domain YES, encapsulate persistent data that business logic works on (MS that share the same data aren't really MS!) NO, they aren't supposed to correspond directly (1:1) to slice(s) of actual high-level (for instance: user-facing) applications Why not? MS are NOT a…

Read More

Pit of (coupling) snakes - communication contracts (when done wrong)

Pit of (coupling) snakes - communication contracts (when done wrong)

The struggle against coupling doesn't just seem eternal. It IS eternal. Multi-dimensionality (compile-time, deploy-time, run-time, ...) of the problem, easiness of breaking the state that was achieved with the great effort, complexity of validation / monitoring (try to quantify coupling in a way that makes sense ;>) - all of these don't make things easier. Especially when you realize that sometimes you've got snakes in place you've considered relatively safe & harmless - in my case: contracts. By contract I mean shared metadata used to describe format of data exchanged between endpoints. There are several options to maintain contracts (platform- / language- / tech-agnostic)…

Read More