Switching focus at work

Since 2010, I was at work responsible for the infrastructure architecture of a couple of technological domains, namely databases and scheduling/workload automation. It brought me in contact with many vendors, many technologies and most importantly, many teams within the organization. The focus domain was challenging, as I had to deal with the strategy on how the organization, which is a financial institution, will deal with databases and scheduling in the long term.

This means looking at the investments related to those domains, implementation details, standards of use, features that we will or will not use, positioning of products and so forth. To do this from an architecture point of view means that I not only had to focus on the details of the technology and understand all their use, but also become a sort-of subject matter expert on those topics. Luckily, I had (well, still have) great teams of DBAs (for the databases) and batch teams (for the scheduling/workload automation) to keep things in the right direction.

I helped them with a (hopefully sufficiently) clear roadmap, investment track, procurement, contract/terms and conditions for use, architectural decisions and positioning and what not. And they helped me with understanding the various components, learn about the best use of these, and of course implement the improvements that we collaboratively put on the roadmap.

Times, they are changing

Last week, I flipped over a page at work. Although I remain an IT architect within the same architecture team, my focus shifts entirely. Instead of a fixed domain, my focus is now more volatile. I leave behind the stability of organizationally anchored technology domains and go forward in a more tense environment.

Instead of looking at just two technology domains, I need to look at all of them, and find the right balance between high flexibility demands (which might not want to use current "standard" offerings) which come up from a very agile context, and the almost non-negotionable requirements that are typical for financial institutions.

The focus is also not primarily technology oriented anymore. I'll be part of an enterprise architecture team with direct business involvement and although my main focus will be on the technology side, it'll also involve information management, business processes and applications.

The end goal is to set up a future-proof architecture in an agile, fast-moving environment (contradictio in terminis ?) which has a main focus in data analytics and information gathering/management. Yes, "big data", but more applied than what some of the vendors try to sell us ;-)

I'm currently finishing off the high-level design and use of a Hadoop platform, and the next focus will be on a possible micro-service architecture using Docker. I've been working on this Hadoop design for a while now (but then it was together with my previous function at work) and given the evolving nature of Hadoop (and the various services that surround it) I'm confident that it will not be the last time I'm looking at it.

Now let me hope I can keep things manageable ;-)

more ...

Getting su to work in init scripts

While developing an init script which has to switch user, I got a couple of errors from SELinux and the system itself:

~# rc-service hadoop-namenode format
Authenticating root.
 * Formatting HDFS ...
su: Authentication service cannot retrieve authentication info
more ...

Using multiple OpenSSH daemons

I administer a couple of systems which provide interactive access by end users, and for this interactive access I position OpenSSH. However, I also use this for administrative access to the system, and I tend to have harder security requirements for OpenSSH than most users do.

For instance, on one system, end users with a userid + password use the sFTP server for publishing static websites. Other access is prohibited, so I really like this OpenSSH configuration to use chrooted users, internal sftp support, whereas a different OpenSSH is used for administrative access (which is only accessible by myself and some trusted parties).

more ...

Maintaining packages and backporting

A few days ago I committed a small update to policycoreutils, a SELinux related package that provides most of the management utilities for SELinux systems. The fix was to get two patches (which are committed upstream) into the existing release so that our users can benefit from the fixed issues without having to wait for a new release.

more ...

Doing away with interfaces

CIL is SELinux' Common Intermediate Language, which brings on a whole new set of possibilities with policy development. I hardly know CIL but am (slowly) learning. Of course, the best way to learn is to try and do lots of things with it, but real-life work and time-to-market for now forces me to stick with the M4-based refpolicy one.

Still, I do try out some things here and there, and one of the things I wanted to look into was how CIL policies would deal with interfaces.

more ...

Slowly converting from GuideXML to HTML

Gentoo has removed its support of the older GuideXML format in favor of using the Gentoo Wiki and a new content management system for the main site (or is it static pages, I don't have the faintest idea to be honest). I do still have a few GuideXML pages in my development space, which I am going to move to HTML pretty soon.

In order to do so, I make use of the guidexml2wiki stylesheet I developed. But instead of migrating it to wiki syntax, I want to end with HTML.

more ...

Making the case for multi-instance support

With the high attention that technologies such as Docker, Rocket and the like get (I recommend to look at Bocker by Peter Wilmott as well ;-), I still find it important that technologies are well capable of supporting a multi-instance environment.

Being able to run multiple instances makes for great consolidation. The system can be optimized for the technology, access to the system limited to the admins of said technology while still providing isolation between instances. For some technologies, running on commodity hardware just doesn't cut it (not all software is written for such hardware platforms) and consolidation allows for reducing (hardware/licensing) costs.

more ...