14850

Infrastructure Architecture–from the Middle Ages to Now

i often wonder about how we go about performing Infrastructure Architecture in particular and Architecture in general. We spend a lot of time and effort creating frameworks such as Zachman and TOGAF; we create large bodies of data in the form of Enterprise Architecture bodies; we have patterns and reference architecture and the body of white papers and other advertorial content produced by, or on behalf of, vendors.

When it comes down to to actually putting infrastructure on the ground how much of this do we actually use & think about?

Are we like the research scientist looking for  the best answer to solve the problem that we are investigating or are we more like the master mason’s of the Medieval period that built Europe’s great cathedrals, churches and castles?

My feeling is that in many cases we are more like the later.

We have a set of techniques, tricks and tips that we know work because we have used them before. We learn new techniques by working with different people –changing jobs, contractors coming into the organisation  etc.  Often this information ends up being traded. We often serve a long apprenticeship working up through building servers, configuring OS and applications and troubleshooting. When we are deemed worthy – skilled and knowledgeable enough – we are presented with our own projects.

Pretty much parallels the Guild system of the Middle Ages!

Next time you are planning some infrastructure architecture think back on the heritage of how we apply our knowledge. Hopefully one day we will be in the position that it becomes more science than art – when that happens though some of the fun will have gone

The future of Windows administration?

This article

http://www.windowsnetworking.com/articles_tutorials/Seven-steps-Windows-Server-administrators-should-consider.html

suggests 7 things that Windows admins should be looking at:

  1. IPv6
  2. Investigate the cloud
  3. Review licenses
  4. Leverage virtualisation
  5. Pilot VDI
  6. Learn PowerShell
  7. Learn the new DR options

I thought this was an interesting view of the world so decided to add my comments.

Items 3 and 4 are good. Keeping compliant without overspending benefits your organisation tremendously. Virtualise as much as you can is also a good suggestion.

Number 1 – IPv6 – not convinced that its needed yet. Sure later versions of Windows get cranky if we turn it off but at the moment it looks after it self.  There is a mass of technology that still expects IPv4 make sure you are on top of that before worrying about IPv6

Number 2 – the cloud -  at the moment we are in the over hype phase. The cloud will solve all your problems we are told. Recent outages at Amazon, Google and Microsoft have been down played but they would be disastrous if you relied on those services. The cloud is one option to supply services. It may not be the best for you. Investigate but keep an open mind.

Number 5 – VDI – now this one I totally disagree with. All VDI does is transfer a problem from desktop machines to virtual machines. The problem is machine builds and application compatibility. It also costs a lot in terms of hardware. VDI looks to me like a technology to create more hardware sales as we aren’t buying as many servers because we virtualised.

Number 6 – PowerShell – Should be number 1 on the list. If you haven’t started learning it – Why not?  You will need to understand PowerShell if you want to be successful. There will always be room for point and click junior admins but the interesting stuff will be done by the people who can automate

Number 7 – DR – always a good idea but it goes beyond disk based backup such as DPM.

Having criticised the list what would be me top 7 things:

  1. Ensure license compliance – it costs too much not too
    • control the life cycle of OS and applications
  2. Learn PowerShell
  3. Virtualise
  4. Get your high availability, backup/recovery & DR strategies in place. These three are different!
  5. keep up to date with changes in your major OS and application stacks
  6. Investigate application delivery – application virtualisation, Terminal Services/Citrix/VDI
  7. Investigate the cloud

IT lemmings

IT seems to be in a continuous cycle of hype. We keep getting “new” technologies or ways of supplying IT that will solve all of your organisations problems at a stroke. Some examples of this phenomenon include:

  • outsourcing – IT isn’t a core activity for you business so hand over the running of your IT systems to a specialist company who have the experts to deliver what you need and the economy of scale to do it cheaper
  • virtualisation – You don’t need lots of physical servers. Virtualise so that you are running a number of big servers really hard and they host a bunch of virtual servers that are doing the work
  • web services – everything will be available as a web service. Don’t write your own code just string together a set of pre-supplied services and nirvana is reached
  • cloud computing – move everything to Internet access. Let the supplier host the application and you just use it (How is this different from the failed Application Service Provider idea of the late 1990’s?)

Now before you start jumping up and down calling me a luddite let me point out that I am currently working in a environment that utilises three out of these four concepts. I am actively designing new services that employ two of them.

My concern is the misinformation and hype that surrounds “new” technologies. I keep calling it “new” because a number of these are recycled. I’ve already mentioned ASP/Cloud computing. I was working with “virtualisation” technologies on mainframes back in the 1980’s. What goes around comes around.

Each wave of “new” technologies brings a bubble of hype that is totally out of proportion to the benefits to be gained. The IT analyst companies start the ball rolling and the IT press (who usually don’t understand what they are talking about) jump on the bandwagon. Suddenly, the only way your organisation can survive is to throw away everything that has gone before and embrace this new way of doing things.

Reality Check

How many organisations have completely virtualised their environment. I have applications that can’t be virtualised because the vendor won’t support it in a virtual environment?

How many external web services does you company really use?

Can you run your organisation in the cloud? Many can’t because of regulatory or commercial restrictions that prevent it. This is often due to access to the data.

 

All of the ideas that are bandied about need consideration. Just because its new doesn’t mean that it suits your organisation.

This is where the good architect earns their money. Separate out what will benefit your organisation and utilise it. Ignore the rest. ignore the analysts and IT press telling you what you should be doing when they don’t have a clue what your organisation really needs.

There are organisations that will benefit from cloud computing. There are others that it will harm. Virtualisation is delivering benefits to the organisation I work with – but don’t forget the overheads that come with it.

One of my favourite phrases when discussing technology is “so what”.  Meaning what does it actually do for us? Does the benefit of implementing out weigh the cost?

This continual jumping towards the next shiny toy is why many businesses hold their IT departments in such low regard? The planning should always be from business process to applications to infrastructure to support them. Leading with technology doesn’t work and will continue to cost businesses money they possibly can’t afford.

Science or Art

Infrastructure Architecture = Science or Art. Discuss.

We claim the titles of architect and/or engineer but is what we do as infrastructure architects really based on solid scientific/engineering principles.

I would claim not. Much of what we do is recycling the designs of the past – possibly adapting them as new versions of particular technologies appear. But how many times have you seen an implementation of version 3 of product that is implemented in exactly the same way as version 1 would have been. The reason is usually the very lame “but we’ve always done it that way”. The real reason in many cases is that the people involved haven’t bothered to keep up to date with changes in the technologies they are relying on. This means their organisations aren’t getting the full benefit of those applications.

There are a number of fundamental architectural decisions that in many cases are driven by the existing environment. How many truly green field sites are there these days?

There are a larger number of design decisions which are often based on the products we select.

In this way we are more like the master masons that built the great cathedrals of the Middle Ages. We know what works and we stick with it.

So. Science or Art?

Architecture and Design

When we are talking about IT infrastructure the terms architecture and design seem to be used with identical meaning – even by practising architects who should know better.

The two concepts are quite different.

A architecture is how we want deliver – the concept if you like.  I have seen this level labelled as conceptual design which in many ways is a better label than architecture. As an example we will consider the Windows server estate of an organization. It has been decided that architecturally the roadmap is to virtualise. Our architecture looks like this

  • Server farm  - hosts for virtualisation
  • hyper-visor and management system for virtual machines
  • SAN based storage for virtual machines

For simplicity I’ll leave out backup, networks etc etc. They are assumed to be present.

Notice that I haven’t mentioned a single product. Architectures are product agnostic.

A design is what we will actually implement.

There are a number of designs we could create to satisfy this architecture.

For instance:

  • 5 IBM based servers
  • VMware + vcenter
  • IBM SAN

or

  • 5 HP servers
  • Microsoft Hyper-V + SC Virtual Machine Manager
  • EMC SAN

we could continue building options. In many cases buying policy and/or existing infrastructure dictate the solution.

In any case these designs have the same architecture but they have different designs and implementations.

Architecture is product independent – Design is when we decide on the components we are using and pick the products.

Architecture, Administration and Automation

At first glance these three topics may seem to have nothing in common apart from the fact that they all begin with the letter “A”.  They are however intimately linked as we will see.

Architecture in an IT sense has many definitions (one per practising IT Architect at the last count) but I regard it as a the set of principles  around which you design your IT. To keep it simple I’ll restrict the discussion to infrastructure. I have heard much debate about the difference between architecture and design. I have a simple view – if products are mentioned its a design. As an example the decision to utilise virtualisation is an architectural one but whether to use Hyper-V or VMware for instance is a design decision.

So now we’ve decided what architecture is what its impact on administration. Quite simple really. One of the biggest problems facing IT administrators today is the complexity of the environment they are working in. You can easily find yourself in an environment with six versions of Windows (NT, 2000, 2003, 2003 R2, 2008, 2008R2 – I know the first two are out of support but I bet a lot of organisations are still using them) and that’s before you add in the complexity of 32 vs 64 bit and standard vs enterprise (or even datacenter) editions. Add a few applications – multiple versions and editions of SQL Server, a few Exchange servers, SharePoint, web servers, a raft of third party applications  -  plus file and print gives you a wide spread of skills that are needed. We mustn’t forget Windows itself plus the necessary additions of Active Directory and DNS. We haven’t even got to  the client systems and their applications which further muddy the waters.  Then we get to servers – virtualised plus one or more of the big vendors (usually more) and a whole bunch of different models add to the fun. The odd Linux or Unix server just to keep us awake and all the network, remote access and other issues and we end up with a very busy set of people.

It is the IT architect’s responsibility to architect/design complexity out of the environment. Standardise on specific sizes of servers, a single virtualisation platforms, minimise the number of Windows versions etc, etc etc.  This makes the administrator’s job easier because there is a relatively simple, standard set of items to wok with.

One of the biggest causes of downtime is human error. Reducing the complexity of the environment helps to reduce the possibility of error. The other way to reduce human error is to introduce as much automation as possible. The administrator has a responsibility to embrace and use automation to make their jobs easier and reduce errors.  The architect has the responsibility to ensure that the components selected in the architecture/design can be automated using the standard toolset within the organisation.

Architecture + Automation =  improved Administration