Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

It Infrastructure: -able vs. -ed

DZone's Guide to

It Infrastructure: -able vs. -ed

· Integration Zone
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

There are two fairly recurrent memes in IT infrastructure: the There’s an API for that! theme, and the Out of box! theme. It is actually telling that both continue to get play in IT given that they represent polar opposites. Assuming that each has a value, when do you need something that is -able (integratable, orchestratable, programmable), and when is it better to have something that is -ed (integrated, orchestrated, programmed)?

Extensibility or capability?

At the heart of the -able vs -ed decision is whether your primary requirement is extensibility or capability. But even then, which one is better?

The marketing talk around extensibility is that without something that is easily extensible, you will find yourself painted into a corner. To a large extent, this is actually true. Doing an integration once demonstrates that it can be done once, but if an environment calls for many integrations, the capability might not be as important as its repeatability.

Consider for a moment a lot of the network programmability, SDN, and DevOps talk. Common in many of these discussions is the availability of various APIs and constructs that allow things to communicate together. If you are an organization that actively makes use of these APIs (either consuming them directly or buying products from others that consume them directly), then you should care a lot about -able. If, however, you are an organization that does not actually do anything with these APIs, then they likely have limited value to you.

Future-proofing and realizing value

The key here is when one or the other has value. Given this, the extensibility and capability discussion can actually be framed up a little bit differently. Think of extensibility as future proofing your infrastructure. If you are concerned that the environment is changing and you want to have unfettered access to an undetermined future, then -able makes a lot of sense.

But be aware that -able by itself doesn’t actually provide any value. There is a separate step that must be taken to convert -able into -ed. This conversion is what takes future proofing and turns it into something that has a return on investment.

For example, having an API that makes the network programmable is useful if tools emerge that program the network. However, even as those tools emerge, if you continue to run the network the same way, the API has really no function for you. So while it is tempting to buy into the notion of programmable, it might not actually be relevant to your environment.

The point here is not about whether programmability is good or bad; it is that you have to have a view of what is meaningful to your organization. If you have never used the -able side before, do you have line of sight to a change in behavior that makes that more meaningful? If yes, then changing buying behavior makes a lot of sense. If no, then it might not matter that much.

Striking a balance

Because there is inherent but not realized value in the -able side of things, you will ultimately need to strike some balance. Your infrastructure has to be capable, so there is some measure of -ed that has to be included. And you will want to consider how that infrastructure will age and grow, making -able important as well.

As you consider the balance, it is important to be aware of your actual IT practices. It is very easy to elevate the concept of something that might not be that important. In past lives, for example, I have purchased cars that have sizable engines. Forgetting for a moment that I rarely accelerated quickly or hauled something, having the engine seemed better than not having it. But had I considered my actual driving habits, I might have opted for the slightly lower-cost car with the hamster wheel under the hood.

The bottom line

The point here is that the balance for your organization ought to reflect your actual practices. Whether you consider past practices or anticipated practices is an interesting thought exercise, but you should be considering something.

Once you arrive at what is important, then you have to actually shop around for it. If what you need is an -ed network, then you need to look for network equipment that is instrumented, orchestrated, and integrated. How you evaluate equipment changes, and your buying questions should match that. If, however, you are a DIY type shop, then you might look for the -able set of devices.

Wherever you end up, be explicit about what you need. You might find that your needs are better served by different decisions than you have previously imagined.

[Today’s fun fact: Mountain goats are not actually goats. They are antelopes. I wonder if this impacts the naming of facial hair in any meaningful way.]

- See more at: http://www.plexxi.com/2014/06/infrastructure-able-vs-ed/?utm_source=feedly&utm_reader=feedly&utm_medium=rss&utm_campaign=infrastructure-able-vs-ed#sthash.fh9bLTM6.dpuf

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:

Published at DZone with permission of Mike Bushong, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}