#robustintegration Reviewer – Bill Chesnut, Cloud Platform & API Evangelist at SixPivot

Bill Chesnut, @BizTalkBill

image.png

Bill is Cloud Platform & API Evangelist at SixPivot located in Melbourne Australia. He started his career in 1983 with the US Defense as an IBM Systems Programmer. He switched to the Microsoft Windows platform in 1994, and has been involved with Windows development ever since.

Most recently, Bill has been driving various application integration projects using BizTalk Server 2000, 2002, 2004, 2006 and 2006 R2 to connect a variety of Microsoft Business Solutions applications with other systems. Bill is also a Microsoft Certified Trainer and has been actively training BizTalk developers since the release of BizTalk 2004. He is also a member of the elite Microsoft Virtual Technology Specialist (VTSP) team, a small group of selected industry experts working as an extension to the Microsoft Technology Specialist teams. He is also a Microsoft Integration Microsoft Valuable Professional (MVP)

Bill is very involved in the Microsoft User Group Community as leader of the Melbourne .Net User Group. Bill has also been working closely with Microsoft to run the BizTalk User group in Melbourne. Bill is also the primary organizer of the BizTalk Saturday BizTalk Hands on Days around Australia and New Zealand. Bill also maintain a blog at http://www.biztalkbill.com/

He has also spoke couple of times in Integration User Group – Integration Monday

Last year Bill also delivered sessions in Microsoft Ignite New Zealand and Microsoft Ignite Australia

 

It’s really great to have him as one of the reviewer of our book– Robust Cloud Integration with Azure. Here is his thoughts about the book.

1. What do you think about the outline of the book?

I think this book will be a great reference for those integration developers moving from on-premises to the cloud and to help those developers already working in the cloud leverage the full Microsoft PaaS Integration stack.

2. What is your expectation from the book or how do you think this book would be valuable for its reader’s time and money?

There are a number of different technologies in Azure and the question always come up about what particular component to use and when to use them, this book should offer some well needed guidance to help answer those question and get integration developers start on the cloud integration journey.

 

I welcome Bill to our book reviewer team and I am sure his guidance will shape the book to a valuable resource for cloud integration.

Related links:

#robustintegration Reviewers – Howard Edidin & Glenn Colpaert

Howard S. Edidin, @hsedidin

image_thumb.png

Howard S. Edidin is a Cloud Architect/Consultant specializing with Azure PaaS Integration. He is a well know speaker and contributor to BizTalk community. He is also been awarded as Data Platform MVP.

Currently he is working as a Senior Azure Solution Architect with VNB Consulting, Inc. He is specialized in Healthcare and Life Sciences Integration using BizTalk Server and Azure.

He is certified as Microsoft Certified Technical Specialist (MCTS) in BizTalk Server 2010 and is also a Gold Member of the HL7 Organization. He is a Microsoft Virtual Technical Specialist (BizTalk, Azure) for Healthcare (P-TSP) and a member of the Azure Advisory Group.

He is considered the “go to” person for HL7 Integration. Howard is working with Microsoft Healthcare and Life Sciences on the integration of HL7 FHIR with Azure. He was the first to implement FHIR using Microsoft BizTalk Server.

Howard has co-authored three books on BizTalk Server. He also maintains a blog, The Azure DocumentDB  and publishes a Daily newspaper Healthcare Integration

He has also spoke few times in Integration User Group – Integration Monday.

It’s really great to have him as one of the reviewer of our book– Robust Cloud Integration with Azure. Now that he is in the reviewer team of our book, I asked him to share his thoughts on the following couple of questions about the book.

1. What do you think about the outline of the book?

The outline is very thorough.  The biggest issue is trying to keep up with the constant updates and new functionality on Azure.Many of the products and service available in Azure today are in preview.

2. What is your expectation from the book or how do you think this book would be valuable for its reader’s time and money?

The most difficult task is to provide content that is not publicly available on the Azure site or a blog.  Every topic requires at least one good tutorial.

 

Glenn Colpaert, @GlennColpaert

image_thumb.png

Glenn Colpaert is an Integration Consultant and Microsoft Azure MVP at Codit.

He believes its shame to let his learning, experiences, POCs / demos, sit there with no purpose. So he often share his learning and experience with the community by writing a blog post or giving a talk on that subject.

Glenn is also part of the Microsoft Azure Insider program as well as the BizTalk Advisors group.

He became a board member of BTUG.be, the Belgian BizTalk User Group and is an active blogger on the Codit Blog.

He has also spoke couple of times in Integration User Group – Integration Monday.

He has also created a video for Microsoft Channel 9 about Microsoft Cloud Integration and SAP.

He was the first who showed keen interest for reviewing the book after reading the blog post. Here is his thought on the following couple of questions about the book.

1. What do you think about the outline of the book?

After reading the announcement blog post about the robust integration book I reached out to the team behind it and asked if they could use some help with the review of the book. The outline of the book immediately triggered my interest as it tried the cover the broad spectrum of the current integration landscape without losing sight of what’s coming next within the integration space..

2. What is your expectation from the book or how do you think this book would be valuable for its reader’s time and money?

The team behind robust integration is setting some high expectations as they try to cover all important areas of modern/hybrid Integration. Covering the broad spectrum from Logic Apps over API Management to Hybrid Integration with BizTalk Server 2016, this book will definitely will be a must read for all people involved or interested in the current and to be integration landscape.

 

I welcome both Howard and Glenn to our book reviewer team.

 

Related links:

#robustintegration Reviewer – Riaan Gouws, CTO at Synegrate

 

Riaan Gouws, @RiaanGouws74

image.png

Riaan is Chief Technical Officer at Synegrate, a Southern California based software consulting company specializing in on premise, hybrid and cloud based integration. Synegrate is also a Microsoft Gold Partner in Application Integration with specialized skills in Modern Integration (Azure Micro Services and BizTalk Server), based out of Costa Mesa, California. The company has been operating since 2004 as Inobits Inc. and was rebranded as Synegrate in 2014.

image.png

Riaan is a BizTalk Server expert, having worked with the platform since its initial release 15 years ago. He furthermore is a keen supporter of Microsoft’s cloud first strategy and has aligned Synegrate with this strategy. He is also a member of the elite Microsoft Virtual Technology Specialist (VTSP) team, a small group of selected industry experts working as an extension to the Microsoft Technology Specialist teams. He has a strong relationship with Microsoft as a valued partner in implementing enterprise solutions on top of Microsoft Azure.

I got opportunity to work with Riaan during my last project where he was the architect for the BizTalk solution – EDI and EAI, for the enterprise customer. He is amazing person and a great consultant to work with.

Now a days he is mostly involved with customers where they are implementing modern integration strategies using Microsoft Azure. He was the first person I reached out for the reviewer of our book – Robust Cloud Integration with Azure.

Now that he is in the reviewer team of our book, I asked him to share his thoughts on the following couple of questions about the book.

 

1. What do you think about the outline of the book?

I reviewed the book outline and I think it is well thought out, accurately targeted towards integration professionals, and reads very easily. I especially love Chapter 3 – Getting started with API Apps; I think it is comparable to a theme park thrill ride. It takes the user from introduction to API apps, to advanced topics in a quick 40 pages or so. Love it!

clip_image002.jpg

Then the approach you guys are taking with Logic Apps is also great. You start the reader off slow, but then quickly accelerate through the chapters, showing the users basic to advanced concepts on orchestrating data. I also appreciate the fact that you are on cusp of new offerings in Azure, such as Integration Account and Integration Pack.

 

2. What is your expectation from the book or how do you think this book would be valuable for its reader’s time and money?

I expect the book to take an integration developer/architect, with predominantly an on-premise integration skill and mindset, to being knowledgeable and comfortable building integration solutions in Azure. Synegrate is currently involved with customers where we are implementing modern integration strategies using Microsoft Azure. I see readers gaining a lot of knowledge from the book; knowledge that we have gained from practical experience in the field. I think of this book as something that will allow readers to fast-track their entry into getting modern integration solutions built in Azure.

I thanks Riaan to be part of our team as reviewer and also sharing his thoughts about the book.

I wish him and Synegrate very best for their future endeavors.

Microservices: A new approach to building applications

What is Microservices buzzword?

In today’s world, the fast changing demands in business are driving to adopt an application architecture model called “microservices”. Microservices architecture describes a particular way of designing software applications as suites of independently deployable single purpose service. This architecture style definition is provided by James Lewis and Martin Fowler.

Most of us are already aware of software design concepts like

  • Decomposition
    • Promotes separation of concerns
    • Promotes reuse
  •  Shared libraries
  •  Components
    • Process isolation – ability to host a component in its own process space.
  • SOA
    • Services instead of components

Microservices approach is “fine-grained SOA”, an approach of small service instead of monolithic with a single focus. It’s based on a subset of SOA principle – “Single responsibility”.

In contrast to SOA, microservices gives an answer to the question – how big a service should be and how they should communicate with each other? In a microservices architecture services should be small and the protocols should be lightweight. It is an approach to build an application as a set of small single purpose services, each service running in its own process and communicating with each other via lightweight protocols such as HTTP.

Examples of microservices can be protocol gateways, user profiles, shopping carts, inventory processing, purchase order subsystem, payment processing, and queues and caches.

In a recent article from a movie marketing company called MOVIO, they talk about some of the benefits of this microservices architectural style:

  • easier continuous delivery
  • finer grained scalability
  • the team maintains an ongoing relationship with the product
  • each service can use a technology set that is best suited to its purpose
  • makes it easier to incrementally evolve the product

image.png

Source: Microservices: How we walk the walk with Movio Media

Movio found microservices architectural significantly simpler for their analytics-heavy system – Movio Media. Movio Media is a web application, and the system consists of about 20 microservices, each running with multiple instances in production. All of these microservices communicate via JSON over HTTP and run behind load-balanced routers which dispatch requests to the appropriate docker containers on the host.

 

Traditional 3-tier monolithic application model

image.png

The classic three-tier model, with web, business logic and data tiers is shown in the figure below. Due to tight coupling of application services within tiers this model have very little advantage of decomposing application in three tiers.

image.png

A change to any application service, even small ones, required its entire tier to be retested and redeployed. Different modules and services are tightly coupled and any failure could affect the whole system.

When load caused an application to outgrow its hardware, the typical answer would be typically to “scale up,” or upgrade the application’s hardware to add capacity which most of the time requires duplication of whole tier. Also a simple update could have unforeseen effects on the rest of the tier, making changes risky and lengthening development cycles to allow for more rigorous testing.

These all limitation can impact the efficiency and agility in any monolithic application model.

 

Microservices approach to application development

Microservices are a different approach to application development and deployment that caters agility, scalability and reliability requirement to modern application.

image.png

A microservice application is decomposed into independent components called “microservices,” that work in concert to deliver the application’s overall functionality. Each microservice typically encapsulates simpler business functionality, and they can be scaled up or down, tested, deployed, and managed independently.

Key benefits:

  • Agility
  • Autonomous
  • Single Responsibility – strong cohesion and loosely coupled.
  • Technology, programming language or platform agnostic
  • Developed, deployed and updated independently
    • Enables continuous integration and continuous development practices, and accelerates delivery of new functions into the application.
    • Enable superior maintainability in large, complex and highly scalable systems by designing applications based on many independently deployable services that allow for granular release planning.
  • Independently changeable – As long as you don’t break the contracts or interfaces, you can change any microservices implementation under the hood and add new functionality without breaking the other microservices that depend on it.
  • Scaled independently
    • Instead of having giant monolithic application blocks that you must scale out at once, you can instead scale out specific microservices.
    • Failure of one microservice does not cascade to other parts.

One important benefit of a microservices approach is that development teams tend to be more driven by business scenarios which means that smaller teams develop a microservice based on a customer scenario, by using any technologies they choose. Further, individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate for the problem that service is trying to solve.

 

Microservices approach vs Traditional approach

In microservices approach it’s all about efficiency for agile changes and rapid iteration, which enables you to change specific, small portions of large, complex and scalable applications.

image.png

Source: https://msdn.microsoft.com/en-us/magazine/mt595752

Also microservices must own its domain data and logic under an autonomous lifecycle, with independent deployment per microservice

The traditional approach used in many applications is to have a single and centralized database like a normalized SQL database for the whole application and all its internal subsystems, as shown in above figure.This approach looks initially simpler and seems to enable re-use of entities in different subsystems to make everything consistent. But the reality is you end up with huge tables that serve many different subsystems and include attributes and columns that simply aren’t needed in most cases.

Stateless microservices

  • State is external or non existing
    • In the case of stateless microservices, the databases will be external, employing relational options like SQL Server or NoSQL options like MongoDB or Azure Document DB.
    • The services themselves can be stateful, which means the data resides within the same microservice. This data can exist not just within the same server, but within the same microservice’s process, in-memory and persisted on hard drive and replicated to other nodes.
  • Multi-instance and parallel execution
  • Load balancing

Stateless is a perfectly valid approach and easier to implement than stateful microservices, as it is similar to traditional and well-known patterns. But stateless microservices impose latency between the process and data sources, while also presenting more moving pieces when improving performance via additional cache and queues. The result can be a complex architectures with too many tiers.

Stateful microservices

Stateful microservices, can excel in advanced scenarios, as there is no latency between the domain logic and data. Heavy data processing, gaming back ends, databases as a service, and other low-latency scenarios all benefit from stateful services, which enable local state for faster access.

  • State is stored within the service
  • Reliability is achieved by creating replicas on multiple nodes

One drawback in case of stateful services can be the level of complexity in order to scale out. Functionality that would usually be implemented within the external database boundaries must be addressed for things such as data replication across stateful micro­services replicas, data partitioning and so on.

 

Conclusion

If you want to build applications with more control and flexibility that enable you to focus on delivering business value in an agile way then you can consider building your application using a microservice approach.

The microservice architecture breaks down an application into small, independently executing microservices resulting in the following benefits:

  • Agility
  • Autonomous
  • Single Responsibility principle – strong cohesion and loosely coupled.
  • Developed, Deployed and updated independently
  • Scaled independently

But microservice architectures have a higher degree of complexity which requires a PaaS layer to effectively deploy and manage them at scale. This can be handled by using Azure Service Fabric as a microservice platform. Service Fabric provides the plumbing needed to create, deploy, run, and manage microservices in an effective and efficient way.

 

Resources:

https://azure.microsoft.com/en-us/documentation/articles/service-fabric-overview-microservices/

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx

http://movio.co/blog/microservices-walk-walk-movio-media/?utm_content=buffere7738&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer