Posted by Andrew Phillips late at night: December 8th, 2010
A couple of weeks ago, my ever-active colleagues Marco Mulder and Serge Beaumont organised an nlscrum meetup about “Combining Scrum and Operations”, with presentations by Jeroen Bekaert and devopsdays organiser Patrick Debois.
Unfortunately, I was late and only managed to catch the tail end of Patrick’s well-delivered talk explaining how Dev/ops can become Devops. Thankfully, the lively open space discussions that followed provided plenty of interesting insights, comments and general food for thought.
One recurring theme that particularly struck me was the comment, uttered with regret by many in Operations, that they would very much like to help and coordinate with the development teams but inevitably were always too busy keeping the production environment up and running.
In other words, helping prepare for new releases might be desirable, but achieving the five nines, or whatever SLA Operations has committed to1, will always be paramount.
This is a fallacy! Indeed, one of the core realisations of the “Devops mindset”, to me, is that 99.999…% uptime is not an end in itself, but a means to an end: delivering the greatest business value possible. And aiming for the highest possible availability may not be the best way to go about it!2
Posted by Gero Vermaas in the early afternoon: December 1st, 2010
At the start of your career your backpack with is filled with lots of theory and as your career progresses more and more experience get’s thrown in, perfect. At some point you won’t be learning new things if you keep doing the same role. That’s why people take up different roles and grow in a team. However, the goal of the team’s you’re in often remains similar: develop system X that realizes user stories Y and Z. Many people do lots of roles, but all on the ‘producing’ side of the IT. I personally experienced the value of jumping to (one of) the other side(s) for a period of time. After returning to my original role I became much more effective.
Posted by Friso van Vollenhoven in the early afternoon: November 29th, 2010
At Xebia, we show a lot of interest in the developing NoSQL community and all the great software and solutions that result from it. Big data analysis and heavy traffic web sites and applications are here to stay and we need solutions capable of dealing with those. The commodity stack of some flavor of relational database with a Java app server on top and the stateful model of server side sessions just doesn’t cut it in some cases. As data volume and traffic grow, these cases will present themselves increasingly often. In our App Incubator program we see a lot of interest in non relational databases and stateless server side setups with more logic on the client side (cleverly coined: NoJSP). Also, at clients the problem of ever growing data sets and the lack of options to do proper analysis with existing tools and databases starts to arise. One of these clients is the RIPE NCC. The story is roughly this: about 80GB of data comes in per day and there is ten years of historical data of the same kind and volume; we need to do queries against this and get sub-second answers. We solve this with the use of Hadoop en HBase.
(more…)
Posted by Jan Vermeir in the early morning: November 16th, 2010
Software vendors have hijacked a potentially useful concept by pushing heavy weight complex tools like ESBs. The goal of this article is to find out which of those tools we really need so we can stay away from unnecessary complexity. I’ll do that by describing the infrastructure services we really need and how these services can be implemented in the simplest possible way.
Software depends on other software because we don’t want to build systems from scratch. Each piece of software your code depends on may:
- change the address or name by which it is known
- change the technology it is implemented in
- be unavailable when you need it
- live on a different server or in the same process
- be connected through infrastructure that cannot be trusted
- speak a different language
(more…)
Posted by Jan Vermeir in the early evening: October 7th, 2010
Most IT careers start with a programming job: you write code in one of the popular programming languages as part of a team. As your experience grows you start to get bored with software: you’ve been working with more or less the same technology and tool set for a couple of years and you need something new to keep yourself going. That’s the point where you have several options like becoming a project manager, coach, analyst or middleware expert. This story is about another option: becoming an architect.
(more…)
Posted by Sander van den Berg in the early evening: August 11th, 2010
Over the last 4 month’s we have written a series of blogposts describing 11 principles of Lean Architecture. This post will be the last of the series, the wrap up post.
Posted by Denis Koelewijn in the early evening: August 10th, 2010
This is the eleventh and last post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The eleventh principle we discuss is called “Freedom where possible, standardize where needed“. (more…)
Posted by Gero Vermaas in the early afternoon: July 28th, 2010
This is the tenth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The tenth principle we discuss is called “Architecture emerging from Projects“. (more…)
Posted by Sander van den Berg in the early evening: July 21st, 2010
This is the ninth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The ninth principle we
discuss is “Comprehensible over Comprehensiveness”.
Posted by Wilfred Springer in the early afternoon: July 21st, 2010
How did we end up here?
Fifteen years ago, at the end of the two-tier client server age, people started to realize the importance of distinguishing between at least three different layers in the architecture. A business layer, providing a convenient API allowing you to address a particular business concern, a data layer storing related data, and a presentation layer providing a convenient user dialog on top of the business logic.
