|By Jim Webber||
|October 27, 2003 12:00 AM EST||
With the emergence of Web services into the mainstream the developer has to learn how to architect and build service-oriented systems. While service orientation isn't a new concept, the rapid convergence of the industry on Web services technology has brought the concept of service-oriented architectures (SOA) to the forefront of many developers' minds.
Over the last decade we learned how to construct software systems using patterns that adhered to the concepts of object orientation. Now, service orientation requires us to adapt to a new approach to system integration and application development. However, at the moment most of us are still learning about this new technology and so we tend to apply familiar patterns when building Web services–based applications.
Applying object-oriented patterns to service-based systems is generally a poor idea since the scale of a typical object-oriented application (generally within a single enterprise or department) is dwarfed by the scale of a Web services–based application (which may span many enterprises and departments). It is crucial to remember that the use of SOAP and WSDL in our applications does not constitute service orientation.
This article outlines the basics of (Web) service-oriented architectures and looks at the distinguishing features of SOA that make it the right approach to take when developing Web services–based applications. We define the concept of a service, compare the emerging service-oriented programming to object-oriented programming, and outline how to advance to SOA. Finally, we explore these concepts in the context of an example banking system.
What Is a Service?
In order to understand SOA, we must first understand what an individual service is. A service is a logical manifestation of some physical resources (like databases, programs, devices, or humans) grouped as a process that an organization exposes to the network. A Web service is therefore best thought of as a "user interface for computers" and, just like GUIs for human consumption, a Web service provides controlled access to some underlying computer system (see Figure 1).
A Web service is the set of actions that the hosting enterprise is prepared to execute. A Web service does not expose a set of operations, methods, or functions (though WSDL uses similar names). Instead, it advertises the set of structured messages that it will exchange. When a message is received by a Web service, the appropriate action is performed and a response message may be returned. There is no assumption that subsequent messages received are associated with prior ones (i.e., Web services are stateless), nor are services mutually dependent – the fact that we concentrate on message exchanges, rather than interfaces, supports this notion.
Service Orientation Versus Object Orientation
Perhaps the most important difference between service orientation and object orientation resides in the way software integration is achieved. Fundamental to object orientation is the concept of a type system that is shared among software components. In the general case, a hierarchy of interfaces has to be agreed upon in advance, before those software components can be integrated.
In contrast, services and their consumers achieve integration through the exchange of messages. The only thing that is shared between them is the vocabulary used to define the structure of those messages, which – in the case of Web services – are XML and XML Schema. The absence of a predefined type system enables loose coupling since no information needs to be shared among services and consumers, before implementation and deployment. Service orientation is more appropriate when (potentially heterogeneous) platforms are to be interconnected.
Furthermore, in object orientation, software entities (objects) are smaller units of abstraction than services (e.g., an account versus a bank). Hence, fine-grained interactions are encouraged between these objects and the formation of complicated webs of interrelations and dependencies between them (e.g., objects may hold references to other objects) cannot be avoided. Conversely, service orientation promotes coarse-grained interactions and the reduction of dependencies between services. In this view, we propagate "chunky" messages around a Web services–based application, which contains all the necessary information to invoke an action. Good service-oriented design mandates that all the information necessary to invoke an action is contained in a message, unlike object orientation where "chatty" interactions between client and serving object are the norm. Since Web services are likely to be remote from the application that consumes them, fine-grained interactions will perform poorly because of the overhead imposed by network communication (and indeed the additional XML infrastructure needed), and so it is imperative that coarsegrained interactions are supported. Once we have decomposed a problem domain into coarse-grained message exchanges supported by schemas to describe common vocabularies we are ready to step up to service-oriented architecture.
Stepping Up to SOA
The transition from object orientation to service orientation is not necessarily straightforward, because of inertia more than any real complexities of the approach. As developers and architects that have learned and used object-oriented patterns in distributed application design for more than a decade, we cannot expect to adapt overnight to this new architectural paradigm. Indeed, in the current world of Web services we see examples of old approaches to distributed application development presented as service orientation.
For example, early SOAP toolkits unwittingly encouraged an object view of the world by making SOAP RPC extremely easy to use, an approach that has been deprecated by the community through the WS-I basic profile. Current SOAP toolkits make it very easy to create a one-to-one association between a Web service and the implementing object (e.g., expose EJBs as Web services or create a WSDL of a Web service from a single class). A Web service should be more than that; it should be a front end to a set of objects, programs, databases, humans, etc. A particular symptom of this mindset is the use of the term "operation" in WSDL to describe the set of messages that are related to a particular action of a Web service. This is unhelpful since it has the same kind of connotation as terms like "method" and "function", where it is better to think in terms of messages. Thinking in terms of messages not only forces designers to think in terms of coarser granularities, but also detracts from the problematic notion of shared type systems where messages, not typed interfaces, are shared between components.
Stemming from this mindset, it is not uncommon to see Web services technologies used to violate enterprise encapsulation by exposing internal resources to the Web service consumers. This inevitably results in an integration nightmare and fragile applications where easily broken interrelationships can be formed that cross enterprise boundaries. We have seen examples of this in particular application domains, like the grid, where Web services are used to support characteristics like stateful interactions, service transience, factories, publicly visible state, and introspection, which are borrowed from object-based systems like CORBA and J2EE and applied to Web services in a manner that carries the danger of tight coupling. Effectively, a common component model is built on top of Web services when one is not required. Component models are ideal for building closed systems but are not suitable for enterprise-to-enterprise integration. The dangers of layering an object model on top of Web services technology are shown in Figure 2.
The Bank Service Example
The best way of demonstrating these concepts is by an example taken from our day-today lives, the "banking service." A banking service is an abstraction of a set of actions that are offered by the bank to authorized users. We may be able to open/close accounts, deposit/withdraw money, get/repay loans, transfer money from one bank to another, pay/cash checks, establish financial agreements, finance a business, and so on.
As customers of the bank, we don't have to see any of the underlying technologies, methodologies, resources, and practices that the bank uses in offering its services. We are free to use any of the available interfaces to access the same offerings albeit at different levels of quality of service. For example, we can use our computer at home, the telephone from work, one of the many ATMs on a street, or even walk into any of the branches of the bank whose service we want to access, as depicted in Figure 3. In all of these cases, the business logic is controlled by the banking service. We are merely presented with a human-toservice interface.
When interacting with our banking service through one of these interfaces we use a common problem domain vocabulary like the terms "account" and "money" or the actions "deposit" and "borrow" as the basis for message exchanges with the bank.
For example, when we want to withdraw money from our account, we are not presented with the actual account "object" and asked to withdraw the money via a "method call" on that object. We don't know, or need to know, how the information about our account is maintained by the bank. Instead, we interact with the bank through message exchanges that result in some money being withdrawn.
Taking this approach one step further, we can consider message exchange patterns provisioned through Web services technologies that enable other computing systems to interact with the bank. The way the bank manages its infrastructure and resources and the way it operates does not have to change – it's business as usual. Remember that Web services is an enabling technology for computer-to-computer interaction rather than a radical new way of doing business. So, even though our bank has deployed a set of Web services as a way to access its business logic, it still does not have to expose its internal resources, implementation details, or practices. What Web services have brought to our banking example is the ability to automate interactions that cross its administrative boundaries.
Now it's possible for programs running on computers that are not controlled by the bank to consume the banking service and, perhaps, combine it with business logic that is unknown to the bank. We can envisage a personal finance application that can talk directly to our bank through Web services and at the same time combine information from our credit card provider and stock broker to offer us an up-to-date view of our financial situation. Of course, a Web services–based approach enables us to scale this application up to enable the integration of our banking service into larger processes and its participation into automated business-to-business activities (see sidebar, "Service Interactions").
The advent of Web services means another paradigm shift for the development community. As with the previous paradigm shift to object orientation, we are going to have to learn (sometimes by our mistakes) how best to apply this new paradigm to designing and building our applications.
Though it is tempting to view this new style as objects-plus-XML, this is a strategy that will hamper the development of truly scalable and loosely coupled services. Instead, we should aim to deliver services that expose coarse-grained processes to our partners (and not simple get/set operations); we should build stateless services for loose coupling; and we should not expose (even conceptually) any resources from a service back end directly to a consumer because this makes applications brittle, and unable to cope with change.
Though these are simple rules of thumb (see sidebar, "SOA Checklist") and we expect our understanding of how to deploy this technology will become vastly more sophisticated in time, for now we believe these constraints are a good starting point to making applications truly service oriented.
We would like to thank Mike Sick from Serene Software for his valuable comments.
Some interaction patterns are more sophisticated than those offered by plain stateless Web services. For example, when we stand in front of an ATM we don't have to identify ourselves as part of every request for an action. Instead, we establish our identity and the account we want to operate on at the beginning of the interactions. Subsequent action requests take place within the "context" that has been established between us and the banking service (a feature that is implicit in an object-based system since we bind directly to a serving object).
However, we can achieve similar contextual semantics with service interactions. Back-end resources like the account remain hidden from the service consumer, but we establish a context that we can use at the application level to "group" actions together. There are two possible approaches rising to prominence in the Web services community:
Which approach we choose is determined by our deployment scenario since both broadly achieve the same goal. Where the simplicity and potential interoperability benefits of a standard, explicit context–based approach are appealing, we need additional infrastructure to deal with context generation and lifetime management. Conversely, with the implicit correlation-based approach, we need no external infrastructure, though we run the risk of altering message content solely to be able to generate uniqueness (e.g., by adding a unique "message id" field where there is no business-level requirement).
Whichever context form is selected, the upshot is the same: context allows consumers to have "stateful" interactions with Web services, but does not require back-end objects to be exposed. This means the Web service has a free hand in deciding how to manage its back-end resources, since they remain encapsulated away from the consumer. This is in contrast to the object-based approach, where invocation context is set by references to objects and the invocation history of referenced objects. The big drawback with this scheme is that object references between enterprises are likely to be brittle and impose too tight a level of coupling between the client and the serving object.
|Savas Parastatidis 11/25/03 11:54:35 AM EST|
Thank you very much for your interesting comments.
I mostly agree with your description of a service. To me a service is an entity (possible a software one) that adheres to a contract. A contract defines the format of messages that the service may send and receive. A contract also defines the message exchange patterns in which the service is prepared to participate.
I totally agree with you that the Web Services Architecture is a realisation (one of the possible many) of the SOA concepts. In fact, one could argue that CORBA services attempted to implement the same concepts. I believe that CORBA services were a step towards the right direction but they still had to carry the "garbage" of the globally shared type system for one single application. This is not so with Web Services where we only share the knowledge XML, XML Schema, SOAP, and perhaps WSDL.
As for notification... Notification is a pattern and as such I don't see why you think it's not implementable in a service-oriented world. You could have a look at the myGrid notification service (a research project) at http://www.mygrid.org.uk for such a service.
SOA does not impose a request-response pattern. You may have different message exchange patterns defined by a contract.
|Savas Parastatidis 11/25/03 11:54:10 AM EST|
Thank you for very much for your feedback. As you probably already know from this article and you will see from two future articles, Jim and I disagree with your view. We do believe that there is a difference between object- and service-orientation. The former is built around the concepts of objects and classes while central to the latter are messages and contracts.
Is service-orientation something new? Of course not. As with most things in computing, it's an evolutionary step. We rarely see revolutionary ones.
Have we been doing service-orientation with CORBA? To a certain extent, yes. The benefits of loose-coupling, interoperability, scalability, and boundary preservation are not new in distributed computing. Service-oriented architectures (SOAs) didn't just introduce them. We have been trying to build distributed applications with such characteristics for years. Service-orientation is another paradigm that aims to further enable the implementation of such applications.
The Web Services Architecture (WSA) is a realisation of the SOA concepts and an evolutionary step in our efforts to build more loosely-coupled, scalable distributed applications.
Some more comments are inline...
You have just described the role of Interface Description Languages (IDLs). Their role in this world is to describe interfaces of instances of a shared type, a shared abstraction. Once that is done, methods on those instances may be invoked remotely.
That is not so in SOAs where we agree on the format of the messages that are exchanged between services. There is no concept of a remote procedure call. In fact, we don't even know whether a service is implemented in a language that supports procedures or objects. The only thing we know is that if a service is given a message of a particular format, we may get (according to the message exchange pattern) a reply in the form of another message with a well-define structure. The description of the message formats and the exchange patterns makes the contract. We hope to have an article on this exact topic very shortly. Stay tuned.
> "We have seen examples of this in particular application domains, like
I disagree with your statement that "the Grid is not an application domain, it is an infrastructure". Granted, the Grid means different things to different people. However, we were referring to the specific efforts within the Global Grid Forum and the Open Grid Services Infrastructure (OGSI) specification. The Grid is an application domain and OGSI defines the infrastructure for it, according to those involved in most of the GGF working groups. The Grid is an application domain with its own requirement. It is nothing new in terms of distributed computing. It just imposes new challenges on how the distributed computing concepts can be applied at a large scale.
We believe that OGSI defines an object-based component model on top of Web Services, which is fine. In fact, during discussions in the last GGF meeting, the OGSI authors agreed that to be the case (look for Dr. David Snelling's presentation at the OGSI WG web site, https://forge.gridforum.org/projects/ogsi-wg). It's just that we believe it is possible and preferable to build Grid applications without the concepts introduced by OGSI but, instead, with just Web Services.
I agree with your second statement. These are indeed useful tools in an object-oriented view of the world. However, in a service-oriented world, they are not really necessary. You don't create an instance of your favourite banking service in order to withdraw some money, do you? Services are there, they exist, they are offered by a service provider.
> "When interacting with our banking service through one of these
The one described by the contract, the WSDL.
> 2. Surely a method call simply is a way of sending a message to an
Sure, you can hide implementation technologies behind an interface and you can have information encapsulation in a distributed object-oriented environment. Technologies like CORBA, DCOM, JavaRMI, etc. tried to do that but not with great success. They made too many assumptions on what it is shared between the different distributed components of the entire system (i.e., types). In Web Services we only share knowledge of XML and XML Schema for messages and we have a way to describe contracts (i.e., WSDL).
Again, thank you for your comments.
|Greg Wdowiak 11/13/03 06:41:15 PM EST|
In addition to Iyad's comments that I agree with:
1) To me the SOA is an approach to constructing enterprise systems from components in which:
- a system consists of a COLLECTION of interacting services, each of which providing a well-defined collection of functionality, available over the network.
- at the core of an SOA system is a service. A service is a DISCOVERABLE software entity that offers coarse-grained functionality through well-defined, published interface. A service is offered by a service provider ? a software entity that implements the service specification.
-- a service is accessed by a service requestor. A service requestor may be a client application or a service itself.
-- SOA is enabled by an SOA broker. An SOA broker (be it centralized or distributed) provides:
-- Service invocation infrastructure allows the service requestors to bind to a service and invoke it .
2) The Web Services architecture is a popular EXAMPLE of SOA. Conceivably SOA may be implemented without Web Services at all!
3) An interesting question is:
|Simon Thompson 11/11/03 05:50:55 AM EST|
"The absence of a predefined type system enables loose coupling since no information needs to be shared among services and consumers, before implementation and deployment."
|Savas Parastatidis 11/06/03 10:20:15 AM EST|
Yes, of course it is :-) If we were all in agreement we wouldn't have
> However, I would really like to understand the points you raise in a
> Don Box, I still stand by the notion that SOA is a natural evolution
I don't think we've ever suggested that SOA was not a natural evolution
Web Services is a clean, new approach to service-orientation where we
> Before we get into the specifics, I would like to comment on the
> of a particular implementation of a service any easier or harder than
> true even if they have used CORBA. In a matter of fact, one of the
I saw all Don Box's talks last week at Microsoft's PDC and I totally
With CORBA IDL you assume that you have a common understanding about the
That's no so in SOA and Web Services. Amazon.com can evolve but
> Nevertheless, the author does state that SOA complements OO, not
I think that there is room for both at different levels. In fact, our
> Back to your article and to help us get on common grounds. Here are
I think that's what we are doing. We are talking about distributed
> - WSDL provides a description of what a service is capable of
I don't agree with your description of WSDL. WSDL is a contract not an
WSDL defines the structure of the messages being exchanged and nothing
> - If you agree with my description of WSDL above, then don't you see
As you see above, I don't agree with your view on what WSDL does. I
Having said that, it's much easier to evolve the XML Schema without
> - You said that there are misuses in SOA already, but the same is true
As I said earlier, you can do service-orientation using object-oriented
> I believe that SOA is an evolutionary step in the industry with
As I said above, I believe that CORBA services were a step to the right
Also, I disagree with your comment about CORBA and standards. There has
And it is the misuse of such technologies when building Web Services
> Will be interested in your feedback.
Again, thank you for your very interesting comments.
|Iyad Jabri 11/05/03 12:46:16 AM EST|
Thank you for your candid response. We might be in disagreement and that is ok. However, I would really like to understand the points you raise in a little more details out of a genuine interest in learning something new. Even after reading your response and one of the referenced articles by Don Box, I still stand by the notion that SOA is a natural evolution of distribute OO (DOO). There are a lot of commonality and some implementation differences and some subtle but important conceptual differences?which I would defer so we can keep the dialog to a manageable scope.
Before we get into the specifics, I would like to comment on the article by Don Box. I thought it was a good article with good insight into Microsoft Indigo. However, I don't think it was neither fair nor accurate in comparing SOA as a concept and architecture vs. OO as an implementation in the Service-orientation Fundamentals section. As an example, it compares the deployment of services in SOA vs. applications in OO and all of the version/binary-compatibility challenges. There is nothing inherent in SOA that will make deployment of a particular implementation of a service any easier or harder than in any other distributed architecture. His example of amazon.com holds true even if they have used CORBA. In a matter of fact, one of the principle goals of CORBA is that an IDL can exist far before you have any implementation or consumers of it, regardless of adopted technology.
Nevertheless, the author does state that SOA complements OO, not supersedes it?which I?m in total agreement with, and was the main point I was making in my previous email (different patterns for interface layer vs. app logic layer).
Back to your article and to help us get on common grounds. Here are few points of what I think SOA is/isn't and I would like to know whether you agree with these points:
- In a full implementation of logic, SOA is appropriate for the interface/facade layer, but not the concrete/detail implementation of the logic. In other words, I don't believe that everything is a service and a service invocation, kind of like the motto in OO that everything is an object. If you agree with this then it's not fair to compare OO to SOA. Instead you should compare SOA to the various DOO architectures.
I believe that SOA is an evolutionary step in the industry with revolutionary impact. Just like HTML/HTTP/TCP/IP were the foundation of the Internet boom, having the entire industry agreeing on a set of standards like SOAP and WSDL, for example, will grow the use of the Internet (both in depth and breadth) far beyond anything we?ve imagined. However, even though XML and XML Schema have some advantages over IIOP, if the entire industry agreed on IIOP, the same impact can be achieved. The article about Indigo that you've referenced is a great example of how similar most of the services in a SOA implementation to CORBA services. A lot of developers looked at CORBA as just an ORB, while it's a comprehensive architecture of building and integrating distributed applications that can span the globe and are developed at different times by different parties. I know that I sound like a big CORBA supporter, but that is not the case. I'm just pointing out similarities with existing architectures so we can leverage the lessons learned, and highlight the important differences.
I also believe that there is a great marriage between SOA and OO. OO programming languages make great implementation platforms for SOA services. I think that C# in .NET and Java with TME Glue (now webMethods Glue) make good examples of my statement. Both support code-first and WSDL-first development models. Mapping services to facade interfaces/objects are very natural, and using OO for building the detailed implementation leverages the advantages of OO over procedural languages. However, both can be properly used and misused in building web services.
Will be interested in your feedback.
|Savas Parastatidis 11/04/03 06:57:51 PM EST|
Obviously, as you read from our article, we do not share your view. We actually see a difference between Service-Orientation and Object-Orientation. In Object-Orientation, it is necessary to share an understanding about the underlying type system and the behaviours that are realised through the sharing of interfaces/types. Type sharing results in systems that cannot evolve easily, especially when they are distributed and not under a single entity?s control. The evolution of one interface/class may break the entire system. The result is tight coupling.
Services on the other hand are deployed, implemented, and maintained independently. They have well defined boundaries and they communicate with others through messages. The only common understanding that is shared between services is how to do message validation. Services define the message-exchange patterns and formats of those messages that they are willing to accept. Hence, loose-coupling is achieved.
In Object-Oriented system we share behaviours and an entire type system, not just message formats.
Pass-by-reference is a valuable pattern in cases where we are in control of the entire system as it results to tight coupling. In a SOA environment, it would result in resources being exposed outside a service?s well defined boundaries. I expect that in some cases (e.g., huge datasets) a form of pass-by-reference will be created but not as we know it. It is not within the scope of SOA to expose objects/resources/entities in that manner. Access to such resource could be achieved through contextualisation (e.g., WS-Addressing).
After Jim and I submitted this article to the WSJ, we found out that we were not alone in our understanding of SOA when compared to OO. In fact, influential people like Don Box  &  have very similar ideas (or, I should probably say that we have similar ideas to him:-)
1. Box, D., Service-Oriented Architecture and Programming (SOAP) - Part 1 & Part 2 talks from the MSDN TV archive (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030827SO..., http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030902SO...). 2003.
|Iyad Jabri 11/03/03 11:07:45 PM EST|
With all due respect, I totally disagree with the author?s comparison between SOA and OO. In a matter of fact, any architect/developer that built distribute object-oriented systems knows to apply different patterns to interface objects vs. implementation objects. For example, interface objects are coarse-grained in comparison to the fine-grained implementation objects. In addition, the implementation objects are completely encapsulated (which is one of the fundamental principles of OO?distributed or not), and are never visible to the outside world except if they were value holder?not much different than complex XML elements described in a WSDL.
The statement that WSDL is so much different than an interface declaration of an interface object (like in an IDL for example) is also not valid. Both describe the terms of a contract between the provider and the consumer. True, pass-by-value was not part of CORBA 1.0, however, it was quickly added before CORBA gained traction. Web services, on the other hand, concentrates solely on pass-by-value (to use IDL terms)?for now:-). I believe support to pass-by-reference, probably in the form of URI, is going to make it into the evolution of SOA. It is interesting how with every new technology trend, we tend to start from an opposite extreme, just to meet back somewhere in the middle.
As a reader, I felt that the article is more mystifying SOA than demystifying it. I agree with the author that Web services are the user interface of a system (more for computers than humans?which is not completely accurate), accordingly, I believe they should be treated as such. In building n-tier systems, we use different patterns for objects that make up the interface layer (top tier) vs. the application logic layer (middle tier). Web services provides us with standards for building the interface layer where new systems can discover and interact with our system, just as a human user discovers a web site and uses HTML to interact with a web application. SOA will play a role in the middle tier, but just as a middleware providing transparent connectivity to the distributed pieces of application logic. Anything more than this is simply mystifying the subject.
That said, there are subtle but important differences that SOA brings to pure distributed OO development. However, these would be better addressed as a new article/thread.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
Mar. 27, 2017 11:30 AM EDT Reads: 6,666
By now, every company in the world is on the lookout for the digital disruption that will threaten their existence. In study after study, executives believe that technology has either already disrupted their industry, is in the process of disrupting it or will disrupt it in the near future. As a result, every organization is taking steps to prepare for or mitigate unforeseen disruptions. Yet in almost every industry, the disruption trend continues unabated.
Mar. 27, 2017 11:23 AM EDT Reads: 144
SYS-CON Events announced today that HTBase will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. HTBase (Gartner 2016 Cool Vendor) delivers a Composable IT infrastructure solution architected for agility and increased efficiency. It turns compute, storage, and fabric into fluid pools of resources that are easily composed and re-composed to meet each application’s needs. With HTBase, companies can quickly prov...
Mar. 27, 2017 10:30 AM EDT Reads: 2,982
Building custom add-ons does not need to be limited to the ideas you see on a marketplace. In his session at 20th Cloud Expo, Sukhbir Dhillon, CEO and founder of Addteq, will go over some adventures they faced in developing integrations using Atlassian SDK and other technologies/platforms and how it has enabled development teams to experiment with newer paradigms like Serverless and newer features of Atlassian SDKs. In this presentation, you will be taken on a journey of Add-On and Integration ...
Mar. 27, 2017 08:15 AM EDT Reads: 3,151
Culture is the most important ingredient of DevOps. The challenge for most organizations is defining and communicating a vision of beneficial DevOps culture for their organizations, and then facilitating the changes needed to achieve that. Often this comes down to an ability to provide true leadership. As a CIO, are your direct reports IT managers or are they IT leaders? The hard truth is that many IT managers have risen through the ranks based on their technical skills, not their leadership abi...
Mar. 27, 2017 05:00 AM EDT Reads: 11,128
The essence of cloud computing is that all consumable IT resources are delivered as services. In his session at 15th Cloud Expo, Yung Chou, Technology Evangelist at Microsoft, demonstrated the concepts and implementations of two important cloud computing deliveries: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). He discussed from business and technical viewpoints what exactly they are, why we care, how they are different and in what ways, and the strategies for IT to transi...
Mar. 27, 2017 05:00 AM EDT Reads: 6,258
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
Mar. 27, 2017 03:45 AM EDT Reads: 3,054
All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
Mar. 27, 2017 03:00 AM EDT Reads: 3,089
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm.
Mar. 27, 2017 12:45 AM EDT Reads: 2,231
As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and micro services. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your contain...
Mar. 26, 2017 09:45 PM EDT Reads: 7,740
As organizations realize the scope of the Internet of Things, gaining key insights from Big Data, through the use of advanced analytics, becomes crucial. However, IoT also creates the need for petabyte scale storage of data from millions of devices. A new type of Storage is required which seamlessly integrates robust data analytics with massive scale. These storage systems will act as “smart systems” provide in-place analytics that speed discovery and enable businesses to quickly derive meaningf...
Mar. 26, 2017 07:45 PM EDT Reads: 9,684
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In his Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, will explore t...
Mar. 26, 2017 03:15 PM EDT Reads: 2,930
DevOps has often been described in terms of CAMS: Culture, Automation, Measuring, Sharing. While we’ve seen a lot of focus on the “A” and even on the “M”, there are very few examples of why the “C" is equally important in the DevOps equation. In her session at @DevOps Summit, Lori MacVittie, of F5 Networks, explored HTTP/1 and HTTP/2 along with Microservices to illustrate why a collaborative culture between Dev, Ops, and the Network is critical to ensuring success.
Mar. 26, 2017 03:00 PM EDT Reads: 10,666
With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend @CloudExpo | @ThingsExpo, June 6-8, 2017, at the Javits Center in New York City, NY and October 31 - November 2, 2017, Santa Clara Convention Center, CA. Learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
Mar. 26, 2017 01:45 PM EDT Reads: 8,668
Everyone wants to use containers, but monitoring containers is hard. New ephemeral architecture introduces new challenges in how monitoring tools need to monitor and visualize containers, so your team can make sense of everything. In his session at @DevOpsSummit, David Gildeh, co-founder and CEO of Outlyer, will go through the challenges and show there is light at the end of the tunnel if you use the right tools and understand what you need to be monitoring to successfully use containers in your...
Mar. 26, 2017 01:00 PM EDT Reads: 1,689
What if you could build a web application that could support true web-scale traffic without having to ever provision or manage a single server? Sounds magical, and it is! In his session at 20th Cloud Expo, Chris Munns, Senior Developer Advocate for Serverless Applications at Amazon Web Services, will show how to build a serverless website that scales automatically using services like AWS Lambda, Amazon API Gateway, and Amazon S3. We will review several frameworks that can help you build serverle...
Mar. 26, 2017 12:45 PM EDT Reads: 2,019
The IT industry is undergoing a significant evolution to keep up with cloud application demand. We see this happening as a mindset shift, from traditional IT teams to more well-rounded, cloud-focused job roles. The IT industry has become so cloud-minded that Gartner predicts that by 2020, this cloud shift will impact more than $1 trillion of global IT spending. This shift, however, has left some IT professionals feeling a little anxious about what lies ahead. The good news is that cloud computin...
Mar. 26, 2017 10:30 AM EDT Reads: 1,334
An overall theme of Cloud computing and the specific practices within it is fundamentally one of automation. The core value of technology is to continually automate low level procedures to free up people to work on more value add activities, ultimately leading to the utopian goal of full Autonomic Computing. For example a great way to define your plan for DevOps tool chain adoption is through this lens. In this TechTarget article they outline a simple maturity model for planning this.
Mar. 26, 2017 06:00 AM EDT Reads: 4,307
While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might...
Mar. 26, 2017 05:15 AM EDT Reads: 6,200
The rise of containers and microservices has skyrocketed the rate at which new applications are moved into production environments today. While developers have been deploying containers to speed up the development processes for some time, there still remain challenges with running microservices efficiently. Most existing IT monitoring tools don’t actually maintain visibility into the containers that make up microservices. As those container applications move into production, some IT operations t...
Mar. 26, 2017 01:00 AM EDT Reads: 3,001