Cloud Architecture

Cloud computing architecture or service oriented architecture (SOA)

The Secret to SOA is approaching the Primitive

CloudMan Cloud Architecture, Service-Oriented Architecture , , , , , , , , , , , , , , , , , , , , ,
Service-Oriented Architecture Diagram

Service-Oriented Architecture (SOA) is a type of software design where services are provided to the other components by application components

SOA works through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.

SOA is clearly rebounding, generally around the arising use of cloud computing. Why? We’ll when we’re dealing with clouds, we’re dealing with services, and when we’re dealing with services we ought to be dealing with SOA. Make good sense?

The common method to SOA is to specify sets of services that could exist physically within the data center, on a public cloud, or possibly in both locations (hybrid cloud). The degree that these services provide useful behavior, and functional habits expected to information, really goes to the value. Nevertheless, I would also state that we have to think about the quality of the services design, the granularity, or how well the services approach a “useful primitive,” and therefore providing even more value.



The capability to create, specify, and establish services at a primitive level goes to the value of those services thinking about that it’s a lot easier to create composites from teams of primitive services. Thus, allowing you to mix and match services to measure up to the specific purpose/requirements of the composite service, procedure, or application, instead of attempting to handle services that are to high level, or course grained, and therefore not a precise fit for your requirements.

An example that I would use is that it’s much simpler to construct a customized developed home using wood, fasteners, or other individual products than to build a home from pieces of another house. The even more primitive the parts, the more versatility you have when developing solutions. As opposed to attempting to recycle a living room.

This is of specific value when thinking about cloud computing. You desire to expose services that offer really primitive and low-level functions, and thus are better to those that want to consume them. Public clouds service providers get this, and therefore provide lots of primitive APIs that appear intricate, but provide a lot more value to those looking to develop company option.

It is necessary that you consider the levels that you specify services, and the more primitive the better. I understand that is a bit counter intuitive, however many aspects of great SOA are. When thinking SOA, inform everyone you’re taking the most primitive strategy.

service-oriented architecture

 

Cloud Integration not as easy as Many Think

CloudMan Cloud Architecture, Cloud Integration, Cloud Services , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Cloud Services

Cloud integration is a process of configuring multiple application programs to share data in the cloud

Diverse applications communicate either directly or through third-party software in a network that incorporates cloud integration.


There are dozens of innovations, cloud and not cloud, which can make this occur. Moreover, there are numerous best practices and maybe pre-built design templates that are able to make this quick and easy.

But, exactly what if you’re not utilizing Integration, and your cloud is a rather complex IaaS or PaaS cloud, that is not as popular and therefore not also supported with design templates and best practices? Now what?

Well, you’re back in the days when integration was undiscovered territory and when you needed to be a bit innovative when trying to exchange info with one complex and abstract system with another. This suggests mapping information, change and transmitting logic, adapters, many of the old college integration principles seem to be a lost art nowadays. Simply since your source or target system is a cloud and not a traditional system, that does not make it any much easier.




The great information is that there are a terrible lot of efficient integration technologies around these days, most of them on-premise with a few of them cloud-delivered. But, discovering to utilize these items still needs that you have a project mentality when approaching cloud-to-enterprise integration, and it’s not an afterthought, as it is numerous times. This implies time, money, and discovering that numerous enterprises have actually not dialed into their cloud enablement projects.

Numerous smaller consulting companies are benefiting kind this confusion and are out there advertising their ability to connect stuff in your information center with things in the cloud. Many fall means brief in providing the value and promise of cloud integration, and I’m seeing far too lots of primitive connections, such as custom programmed interfaces and FTP options out there. That’s a dumb choice these days, thinking about that the trouble as already been fixed by others.

I presume that integration will continue to be an undervalued part of cloud computing, until it becomes the source of many cloud computing job failures. Time to stop ignoring that work that should be done here.

Cloud Integration

Does SOA Solve Integration?

CloudMan Cloud Application, Cloud Architecture, Cloud Integration, Cloud Services, Service-Oriented Architecture , , , , , , , , , , , , , , , ,
Service-Oriented Architecture Diagram

Cloud Service-Oriented Architecture (SOA)

The basic principles of service-oriented architecture are independent of vendors, products and technologies

“So did SOA resolve integration? No. However then once again, no one ever promised you that. As Neil observes, we’ll probably never see a ‘turnkey enterprise integration solution,’ but that’s probably an advantage – after all, organizations have various needs, and such an option would need an Orwellian-level of standardization.”

The fact of the issue is that SOA and integration are 2 various, but interrelated concepts. SOA is a means of doing architecture, where integration might be a result of that architecture. SOA does not set out to do integration, however it possibly a by-product of SOA. Baffled yet?




Truth-be-told integration is a deliberate technique, not a byproduct. Hence, you have to have an integration strategy and architecture that belongs of your SOA, and not simply a desired outcome.You’ll never get there, trust me.

 

The problem is that there are 2 architectural patterns at play right here.

First, is the goal to externalize both habits and information as sets of services that can be set up and reconfigured into options. That’s at the heart of SOA, and the integration typically takes place within the composite applications and procedures that are produced from the services.

Second, is the goal to duplicate info from source to target systems, ensuring that details is shared in between inconsistent applications or total systems, which the semantics are handled. This is the objective of integration, and was at the heart of the architectural pattern of EAI.

Plainly, integration is a purposeful action and thus needs to be dealt with within architecture, including SOA. Thus, SOA won’t fix your integration issues; you need to deal with those directly.

service-oriented architecture

Big Consulting Missing the Cloud Computing and SOA Links

CloudMan Cloud Architecture, Cloud Consulting, Cloud Services , , , , , , , , , , , , , , , , , ,

Cloud Consulting can be an Amusing Occupation

You need to continue to be relevant, so you tend to follow the buzz and follow the group. Cloud computing is the next big thing, and a number of the bigger consulting companies is chasing cloud computing as fast as they can.

However, many are not chasing after cloud computing properly, missing out on a ton of the architectural benefits. Rather they are just tossing things from their business onto exclusive and public clouds and hoping for the best. Making things worse, so many of the bigger enterprise customers do not see through the confusion, or in this case the architecture with the clouds. So, you have both parties taking a reactive rather than a proactive approach to the cloud.



Are you getting the architectural context supporting the use of cloud computing. Or, the ability to produce a total strategic plan and architectural structure, and then taking a look at how cloud computing fits into this framework now, and into the future. Typically that suggests leveraging SOA techniques and patterns.

That message appears to fall on closed ears these days, and the majority of those closed ears seem to be connected to seeking advice from companies that they trust to take their IT to the next level. The end result will be failed cloud computing projects, with the blame being put on the innovation. It’s really the lack of strategic planning and architecture that’s at the heart of the problem.

The concept of SOA, as associated with cloud computing is basic. You have to comprehend the existing and future state architecture before you start picking platforms and technology, including cloud computing. When you have that deeper understanding its fairly simple to find out where SaaS, IaaS, and PaaS come into play, or not. In addition, producing a road map for implementation and migration with time, typically a 3 to 5 year horizon.

Take a deep look at your needs and get an expert to design the architecture before purchasing the apps.

Cloud Consulting

Why SOA using Cloud Requires a New Approach to Testing

CloudMan Cloud Architecture, Cloud Services, SOA Governance , , , , , , , , , , , , , , , , , , , ,

SOA Governance is a Concept used for Activities Related to Exercising Control over Services in a Service-Oriented Architecture (SOA)

One viewpoint, from IBM and others, is that SOA governance is an extension (subset) of IT governance which itself is an extension of corporate governance.
So, why is SOA making use of cloud computing so unusual that we need a alternative technique to testing? As I have actually been stating on this blog site, very many of the exact same patterns around testing a distributed computing system, such as a SOA, are appropriate here. We are not asking you to test that in a different way; only to consider a few brand-new possibilities.
There are some clear screening differences to note when cloud computing enters the mix.Initially, we do not own nor control the cloud computing-based systems, therefore we have to deal with what they offer us, consisting of the restrictions, and typically can’t change it. Hence, we can’t do some types of testing such as finding the saturation points of the cloud computing platform to identify the upward constraints on scaling, or effort to figure out ways to crash the cloud computing system.
That kind of testing might get you a nasty email. Or, white box testing the underlying platform or services, suggesting seeing the code, is also, not supported by most cloud computing service providers, but clearly something you can do if you possess and regulate the systems under test.



Second, the patterns of use are going to be various, including how one system interacts with another, from business to shadow. Typically, we test systems that are on-premise, and almost never ever test a system that we can not see nor touch. This consists of problems with Internet connectivity.Third, we are checking systems that are contractually obligated to offer computing service to our architecture, and hence we require a means to confirm that those services are being offered now, and into the future. Therefore, testing handles a legal element, because if you find that the service is not being delivered in the manner outlined in the contract, you can act.
Finally, cloud computing is fairly new. As such, IT is a bit suspicious about the absence of control. Extensive and well-defined testing, will eliminate most of those fears. We have to be hyper diligent to decrease the opportunities of failure, and work around the fear of what’s brand-new.

SOA Governance

When Thinking SOA Governance, Think Macro and Micro

CloudMan Cloud Architecture, Cloud Services, Service-Oriented Architecture, SOA Governance , , , , , , , , , , , , , , , , , , , , , , , , , ,

Policies, as connected to governance, are declarative electronic regulations that define the right habits of the services.

Nevertheless, they can be guidelines that are not digitally implemented. An example would be policies produced by IT leaders who produce guidelines that everyone have to follow, but the policies are not automated. Or, they can be policies that enforce the appropriate behavior during service execution, generally enforced electronically utilizing governance technology. Both are very important, and thus why we talk about authorities as things that might exist inside or outside of governance innovation.



For our purposes, we can call policies that are more basic in nature macro policies, and policies that are certain to a certain service as micro policies.

Macro Policies

Macro policies are those policies that IT leaders generally produce, such as the venture designer, to address bigger sweeping issues that cover lots of services, the information, the procedures, and the applications. Examples of macro policies include:

• All metadata must adhere to an authorized semantic model, on-premise and cloud computing-based.
• All services should return a response in.05 seconds for on-premise and.10 for cloud computing-based.
• Modifications to procedures have actually to be authorized by a magnate.
• All services should be built using Java.

The idea is that we have some general regulations that control how the system is developed, redeveloped, and monitored. Therefore, macro authorities do indeed exist as well-known easy guidelines, such as the ones detailed above, or set processes that must be followed. For instance, there could be a process to address how the data source is altered, consisting of 20 actions that should be followed, from initiation of the change to acceptance testing. An additional example is the procedure of registering a brand-new user on the cloud computing platform. Or, any procedure that minimizes operational threats.

Many tend to roll their eyes at these kinds of controls that are placed around automation. I make sure you have many that exist within your IT store now. They could also push back on extending these governance principles to cloud computing. Nevertheless, the core value of executing macro policies is to reduce danger and save cash.

The trick is to strike a balance in between too many macro policies that hurt efficiency, or too few that raise the chance that something bad will occur. Not an easy thing, but a good rule of thumb is that your IT department should spend around 5 percent of their time handling problems around macro authorities. If you spend more time than that, maybe you’re over-governing. Less than that, or if you have catastrophe after catastrophe occur, perhaps you can put in more macro policies to put even more procedures around the management of IT resources, on-premise or cloud computing-based.

Micro Policies

Micro or service-based authorities typically take care of a policy circumstances around a specific service, process, or information element. They are associated with macro policies because macro policies define exactly what has to be done, whereas the micro policies specify how a policy is carried out at the most affordable level of granularity.

Examples of micro policies consist of:

• Only those from HR can take advantage of Get_Sal_Info services.
• No even more than 1 application, service, or process at a time can access the Update_Customer_Data service.
• The Sales_Amount information element can only be updated by the DBA, and not the designers.
• The response time from the get_customer_credit service have to be less than.0001 seconds.

Micro policies are extremely particular, and usually destined for execution within service governance innovation that can track and implement these kinds of policies.

SOA Governance

The Truth Behind Standards, SOA, and Cloud Computing

CloudMan Cloud Architecture , , , , , , , , , , , , , , , ,

You can think about SOA as something you do, and cloud computing as a location to do it

Many on the planet of cloud computing think about cloud computing as a new space that requires new requirements. The reality is, most of the requirements we’ve worked with on the planet of SOA over the past few years apply to the world of cloud computing. Cloud computing is just a modification in platform, and the existing architectural standards we leverage must transfer well to the cloud computing area.

SOA Standards are a double edged sword

They plainly offer some value by protecting you from vendor-specific requirements, in this case, cloud lock-in. However, they can postpone things as business ITs await the requirements to emerge. In addition, they might not live up to expectations when they do arrive, and not provide the anticipated value.

 




 

Standards should be driven by existing innovations, as opposed to by trying to define new requirements methods for brand-new innovations. While the latter does sometimes work, more frequently it causes design-by-committee and poor technology. Past failures around standards should make this less of a concern on the planet of cloud computing.

 

So, when considering SOA and cloud computing requirements, take a few things into factor to consider:

Standards needs to be driven by 3 or even more technology vendors that really plan to utilize the standard. Watch out for requirements that include simply one supplier and lots of getting in touch with organizations. Or, are simply driven by advertising and marketing.

Standards should be well-defined. This suggests the devil is in the information, and a true standard should be defined in detail all the way to the code level. Theoretical standards that are absolutely nothing however white documents are useless.

Standards should be in wide use. This indicates that numerous tasks leverage this requirement and the technology that uses the requirement, and they succeed with both. In many instances you’ll discover that standards are still ideas, and not yet leveraged by innovation consumers.

Standards must be driven by the end individuals, not the suppliers. A minimum of, that’s the means it ought to be in a best world. While the suppliers could have had a hand in producing the standards, the customers of the innovation must be the ones driving the meaning and direction. Standards that are defined and kept by vendors frequently fall short to catch the hearts and minds, while requirements kept by technology customers typically offer more value for the end user and thus live a longer life.

SOA Standards

 

Save

Save