The Role of the Cloud Architect

B. Rhubart

It seems logical to start by asking each of you to describe a little bit about what you do. Ron, let's start with you.

R. Batra

I'm a director of products at AT&T, and I focus on AT&T's public cloud services. Currently, I lead a product called AT&T Cloud Architect, which is the infrastructure of the service, and I worked with a few Cloud products prior to this role as well.

B. Rhubart

Jim, how about you?

J. Baty

It's a good question. At Oracle, I work on enterprise architecture and try to understand and build methodology. For the last several years, I have been working on methodology for cloud computing and dynamic infrastructure. I suppose that a simple way of looking at that is, it is pretty straightforward, old traditional-style architecture, but at the same time, the analogy I like to call on is the difference between building a car and building a factory for cars. A lot of what we try to do in cloud computing and the architecture associated with it is construct meta-architecture, these fields of resources upon which applications are dynamically developed and deployed.

B. Rhubart

Ron, does that analogy pair up with your experience?

R. Batra

Yes, very much so. The concepts that Jim described are very much applicable to public cloud architectures. At AT&T I'm product owner for a public cloud. So what that means is I also run it from a profit-and-loss perspective. So when we build a cloud, we look at product features that people want, whether it is akin to a factory or a subfactory or an assembly line, if you will. Depending upon what you're offering in a public cloud, you could say that I have an assembly line and I'm producing axles and I'm going to be the best axle manufacturer, and you have to OEM me out and then join the axle to the rest of the car. Or you could say that I have a full-fledged factory. You come in with nothing and you walk out with a car. So the concepts are very similar. It depends to some degree on the context of a public cloud provider, the offerings, the methodologies that you implement to take a product to market.

J. Baty

I really like that picture because it makes me think of another aspect of this, another dimension. And again, not to pick on traditional architecture, but you used to have everything in your control: I built an app and I installed it on some servers. It's in the data center. It's downstairs in the basement or whatever and I control all the owners. The big trend it IT is towards stuff on the Net, lots of different participants. You go to a website and think you're connecting to one company, but you're connecting to a catalog provider, a content caching mechanism, a payment engine, and these are distributed throughout the Net.

Another effect is the kind of supply-chaining of IT. What Ron just talked about in terms of building the axle, you don't design that axle in isolation. You have to be cognizant of the APIs and the interfaces, RESTful standards, whatever, that your part in the ecosystem plays.

We look at Amazon web services as the archetype of cloud computing. People get really hung up on the APIs or the specific architecture. It's really more about building an ecosystem of services and that ecosystem is more important than a particular, physical implementation. So the supply-chaining of IT, if you will, is a result of cloud computing.

R. Batra

I also look at this as a large scale evolution of web services. What I mean by that is, in late 1999 to 2000, eCommerce came into the picture, and now everybody had a need to do transactions over the Internet. So you had to have a web service, which was basically your credit card service. What the credit card service would do is, you go to any E-retailer to do a shopping cart checkout. At that point it would make a call to verify by credit card company or PayPal or what have you. That was the first evolutionary point where things were not done in one infrastructure, all under one control. But things were disparate and it became a collage, a mash-up of different components feeding into one big picture. So I agree with Jim's view of RESTful APIs and other standards, whether you're using SOAP or HTTP.

The really interesting thing I find is that in the past, when everything was on premise, the architecture had many extremes to it. You had infrastructure architects, you had application architects, you had integration architects, middleware architects, and you had enterprise architects, and you had solution architects. The enterprising solution architects were focused on the entire solution and providing a bridge between the business and the technology groups, while the application architects were very much subject-matter experts in the areas of application, whether it's an off-the-shelf application, like an eBusiness suite or PeopleSoft, or whether it is a custom-written Java app, those are the touch points of the application architects.

The infrastructure architect used to worry about servers, used to worry about storage, used to worry about all the things that make up a data center. But all that is changing, the application architecture and the infrastructure roles. I'm an architect from a pre-Cloud world and now I'm in a post-Cloud world.

J. Baty

You highlighted another trend: the increasing democratization of the activity of architecture. We had these infrastructure architects before, but they dealt with a kind of a stable environment. They were designing a static thing. Their game was kind of like laying out just enough architecture to be able to know where their racks go, how much air conditioning load, placing operating systems, and what's the process for patching. A lot of this involved manual handbooks. You'd walk into a data center and say, "Show me your run book." But now this is about all of us upping our game.

The infrastructure architects were few and you had a lot of people that referred to themselves as systems administrators, and I think they increasingly become those who design repeatable services. They used to design those services and run them themselves. And now, as cloud is a self-service world, those infrastructure architects design services that other people execute, run, call, and rely on, and that changes the level of sophistication, the level of repeatability of what they might have done in the past.

R. Batra

Well, there is that and there is also the trend called DevOps.

J. Baty

Oh, yes! I'm glad you brought that up! I don't think we can have a cloud conversation without it.

R. Batra

So the way I understand it, DevOps is a movement where developers feel empowered to do operational support of what they create versus having a separate operational group. Is that how you see it? What is your definition of DevOps?

J. Baty

I think there's a lifecycle of development and operations activities from the initial planning out of requirements to the ongoing measuring and monitoring of systems in production. There will always be people at the far extremes of these points that exist in a separate discipline. And yet, a big push here is velocity. We move from one release a year to releasing every Wednesday. If you're going to do that velocity, you need tighter coupling and better understanding between development and operations. One baby step in the DevOps movement is to simply take one person from the Ops team and put him on development, and you take one developer and put him on the Ops team, to create a more understanding culture between the two groups.

On the other hand, you could go to the total extreme, which is to have only a handful of people that remain purists and do these kind of lightweight, agile projects, teaming small groups that carry a project all the way through development and operations. I think that's probably reserved for the ultra-dynamic web apps versus traditional enterprise applications. But like cloud computing, trying to define DevOps or put your finger on it, it's a continuum of this kind of aspiration to integrate development and operations.

R. Batra

Right! And with the movement towards cloud different public cloud providers have different offerings. For example, the product I lead at ATT is called Cloud Architect, and we also offer bare metal computing without a hypervisor. Amazon's public cloud, for example, is built on Xen. So it looks almost like a workload provisioning method, to where now you have an application or you have a large environment and you have to choose. Do you want to go to a public cloud, or is a private cloud just the right thing for you? The drivers there are significant in terms of how a business views its spending and everything else.

Assuming there's a decision of public cloud, private cloud, hybrid cloud, in that case, it almost seems like there has to be a workload rationalization effort that says, for a big data application, the big data appliance really works well for me. Or for a traditional NoSQL, this is the right environment for me. Or just a traditional database with a large ERP platform, X and Y and Z are the right structures for me.

So as infrastructure architects, as you say, we have to up our game. Infrastructure architects now have to be able to evaluate, to peek behind the covers of several clouds and really ask the right questions. Can you scale for capacity? What is your over-subscription rate? Do I have a peek into the innards of the system? Do I have access to system logs? Can I know when the system is slow? Do I have visibility into what is making the system slow? Can I run a trace file? Can I actually go in under the covers and see how the system is behaving, or are you hiding all those things from me? So the private cloud is there and that is internal infrastructure, and now you have an external public cloud. In between, there is hybrid cloud, which actually could be a topic of a separate discussion altogether. But it seems to me that the classic infrastructure architect now has to be aware of how to figure out A, a way an application can run, and then B, if there is interop, what is the interop between the different cloud structures. That is a huge, deep subject by itself.

J. Baty

You reminded me of an issue associated with a simple function like load balancing. It's a key component to any kind of distributed computing or cloud environment. When we first did load balancing, it was really just a script hack, a round-robin DNS point that had incoming transactions point to different servers randomly. But more sophistication was needed, algorithms to look at the load on the individual CPUs and systems. Actually, there was also lbnamed, a script to do this. But then people came out with Resonate, and Cisco had their PC- and workstation-based load balancers, and then the switch people compiled that algorithm into ASICs [Application Specific Integrated Circuits] and put it on the switches.

Now, most recently, a bunch of the big eCommerce sites and major internet users have gone back to programming load balancing on general purpose computers. They got fast enough and they got tired of paying for sophisticated switches. But as an architect, it's the same problem. It moves around in implementation from this type of hardware to that type of software and I think as a cloud architect, you have to be sensitive to those multiple types of implementation in designing a sustainable model.

The other aspect you touched on is that we got very good at load balancing. But there's a problem when you say, "Oh, this server doesn't have much load. Well, I'll put all my load on that server. Oops! Now it's down. Now, I'll move all my load over to this other server." Then you've created the firehose effect of not understanding what was happening when we tried to load balance. The algorithms had to get much more sophisticated and we had to look at the time horizon and understand how decisions impacted the overall ecosystem. I think, Ron, what you were talking about is really is an example of that. We have to move beyond simple deployments to really having to be much more sophisticated about load management, about load forecasting and these kinds of issues, either as a cloud provider or as an enterprise consumer.

B. Rhubart

Jim, you mentioned that, "Architects have to up their game," and both of you have talked about how cloud is going to require more from architects, but is there anything about cloud that makes architects lives easier?

R. Batra

It depends upon the perspective of where you are and what your role is as an architect. If I am working for an enterprise and my job is now to develop an architecture, I don't have to worry about a lot of things that I had to worry about in the past. I don't have to worry about servers being assembled together. I don't have to worry about the infrastructure components coming together. I don't have to worry about, in a lot of cases, a large CAPEX approval, because now, it might be an OPEX for me.

So a lot of headaches, which in the past were non-value added time spent on tracking a lot of things, those things are now just table stakes. If I am an enterprise architect or an infrastructure architect, I don't have to worry whether something got racked or not, something had enough power, my data center had enough air-conditioning. If I'm buying something from a public cloud, I just need to make sure I have an SLA [Service Level Agreement] that covers me and I have the right security certifications and ways to interop. So I have already taken myself to a level up in the food chain, if you will, and gotten away from the really intricate details that the systems administration had to do. That is how I see the job being a little easier. Well, not easier, but I would say that it takes away some of the messiness of what we had to do in the past.

J. Baty

I think it could become easier and harder at the same time. Easier in the sense that it focuses more on architecture. Not necessarily architecture as the thing you got your degree in, but at least thinking about architecture. Thinking about interfaces, thinking about scalability, thinking about SLAs, kind of makes everyone value what you do as an architect even more so. And you get to, potentially, think more about the long-term and the higher-level architecture rather than doing architecture after the fact, rationalizing what people had done without governance. I think that makes it easier to be an architect.

On the other hand, it also means that there are dark forces that want to pull some of those architectural decisions away from you. A couple of decades ago we went through end-user computing. Every department or every professor or every group within a company thought, "I don't have to go to IT, I can be IT." Then in the late 90's they started to bring that under control and strengthen the power of the CIO and the enterprise. I think we're having that same kind of influence now.

There is a tendency in companies and organizations to want to end-run the governance model, and there's a danger that they might forget to do architecture on the way to that. So cloud computing makes it easier, potentially, and might put some roadblocks or potholes on your way to architectural success.

B. Rhubart

So it becomes even more of a governance issue. The fact that the cloud makes certain things that much easier creates an even greater need for enforcement, for strict governance over what's happening within IT.

J. Baty

And potentially rewriting your governance model. One of the challenges to governance is you say, "Yes, I'm doing good governance. Yes, I'm complying with the requirements around privacy. I know, because I'm designing stuff myself." When you move into the services ecosystem, you have to be more thoughtful for creating processes and relationships. Ron mentioned service levels. Those service levels become a bit more complicated to manage in some ways, because you have to think about other people doing them. But they become a bit easier, too, because you can select from a menu of cloud providers and cloud offerings as to what's available, and potentially get the best of breed, much better than the hand-wrapped kind of architecture that you might have been doing previously.

R. Batra

Yes, architecture now has to be designed for a longer term view. It's not just after the fact. Architecture now is one of the first things you have to consider. In fact, I'm noticing everywhere, in every business meeting I go to, there has been a refreshing change. Now people talk about architecture right in the beginning.

I would like to add a few things, Bob, to recap some of the skills architects need to pick up to be successful. If you are an enterprise architect or a solution architect, you probably have to sharpen your financial pencil a little bit to be aware of how to capitalize and how to OPEX. It's not something you need an MBA in finance for. You could take a course or two or just learn about MPV and IRR and be able to educate yourself on that. I think that's table stakes.

I'm also see the need for a lot of knowledge of web services, whether a service is RESTful, and about APIs, how to call the APIs and how to make them work. That's also table stakes. It's a question of who is entrusted to do that. In a lot of companies we are finding that it is the applications team that has to understand that because you want to automate operations, and you do automation through APIs.

So anybody can go to a public cloud user interface and choose infrastructure services or any kind of services. Ultimately, you want to auto-scale, you want to automate as many operations as possible. So it's a combination of technology being built into the application layer, or monitoring tools which keep charge of a physical infrastructure as well as an external public cloud infrastructure, or sometimes, a hybrid infrastructure.

B. Rhubart

What both of you have just described is that, just as organizations are contemplating or undergoing their own migration to the cloud, architects, too, must undergo a similar migration. There are new skills to be acquired and adaptations that must be made to integrate into this new environment.

With that in mind, one last question. Does the cloud make easier to evolve within the IT organization? Before we had cloud, things were much more structured. You had a lot of siloed elements within IT organizations and agility has always been an issue, particularly in discussions about architecture. Does the cloud make it easier to move into the future? Does it make that to-be architecture much less of a moving target?

J. Baty

I was with you until your last comment! I think cloud makes the to-be architecture more of a moving target. But I would agree that, far from just making it easier to evolve, cloud makes evolution the goal of your architecture. I used to say that one of the differences with cloud is that everything is the same as we used to do, but it just increases the scale and the velocity to unprecedented levels. If you used to build one data center and patch machines once a year, or write an app and do an app provisioning once-a-year, now you might be doing it every week, every hour.

That means you really are focusing on constantly improving the packaging of the services, the service-level capabilities. You're really looking out farther. So does it make evolution easier? Yes, because you've got the tools to do it. But perhaps more importantly, it requires you to evolve.

R. Batra

Most of the enterprise world was not born in the cloud. You have people who have businesses that were born in the cloud and businesses that were not. So somebody who has come into business existence in the last five to six years may never have actually owned a data center. That generation of people in the computing industry are at a point where their needs aren't about what the data center is. It's going to be pretty interesting for them, because they would always have the notion of the cloud as a moving target. Their drivers for cloud adoption could be very interesting, whether it is lower costs or geographical proximity. Their reasons for moving workloads between clouds and from clouds could be very, very unique.

For larger businesses, enterprises who probably didn't have a cloud footprint, their stance might be that they have assets inside, in an internal infrastructure that we might call private cloud, but now they're looking at external infrastructure and they want to do a hybridized cloud. When you start hybridizing, it becomes a much more complicated picture, because you have to decide where you are hybridizing. Are you hybridizing at the network layer, are you hybridizing at workload, or are you just using backups? The dimensions become more interesting. That could be the subject of a separate discussion altogether.

In summary, I think that life has become more interesting for architects, because you can't just get rid of the old. You have to pick up the new, yet at the same time, most of us will have one foot in the old and one foot in the new. You've got to understand how the old world works, you've got to understand how the new world works, and you've got to be able to bridge the two successfully.

Disclaimer

The views expressed in this interview are those of the participants and do not necessarily reflect the views of Oracle.