Join Now!   |   About Us   |   Contact   |   Sign In
Community Search
Raleigh
Group HomeGroup Home Blog Home Group Blogs
This blog is open for use by all members of the Raleigh chapter.

 

Search all posts for:   

 

Top tags: api  microservices containers docker jenkins data conti  microservices monolith architecture modular  SOA 

How can I be successful implementing Microservices?

Posted By Phil Helm, Wednesday, August 17, 2016

This blog post is one in a series that will give you some insight into the full day training class (Microservices Solution Architectures) I will be teaching at the ITARC Austin on October 6th, 2016

A better question may be "If I can't/don't change , am I going to create business value?" In my opinion, the greater number of changes you can make around the adoption of microservices the greater chance of success with the implementation. 

In my opinion, the best chances for success will rely on the following:

1. Adopting a cloud-first development strategy

The ability to independently build, deploy and support microservices means your existing monolith may turn into dozens, if not hundreds, of vertical business capability slices. Scaling this idea in your datacenter is most likely not going to be successful - unless you have build your very own AWS or Azure from the ground up. In my experience, the cost alone to implement in a proprietary datacenter would be enough to steer away. 

2. Implementing DevOps (or at least, continuous delivery)

How will you truly get the "speed to market" benefits purported by microservices if you can only push code to production every three to six months? The market moves very quickly, and the ability to deliver new and enhanced capabilities at a rapid pace will help differentiate your business. 

3. Organizing around small independent teams

This has to do with dependencies and coupling. If a single large team owns all of the microservices/capabilities, there will inherently be dependencies between capabilities as well as deployments (think Conway's Law). If you want to deliver enhancements to your shopping cart, but it's dependent on (or is a dependency for) your user profile or payment system, your push to production may have to wait to make sure you don't break other capabilities.

4. Adopting a more flexible SDLC

I almost put the word "agile" here, but that is an overused term. I don't know a single engineer or architect that loves waterfall. Your microservices won't love it either. As microservices are small and independent, so should your delivery process be. Is your business going to want to wait six months to review what you have done? What if they don't like it?

5. Implementing a container strategy

Most likely, your microservices will need to be in containers. The speed and efficiency at which containers deploy and exist is far superior to virtual machines.. and chances are, you will need to share resources. What if your microservice needs to live on the same virtual machine as other entities? Now you have a dependency on the specifics of the environment. Alternatively, if a single microservice lives on a virtual machine, is it going to utilize the CPU, disk, memory efficiently?

6. Adopting domain-driven design patterns

Whether you are decomposing a monolith or working with a business capabilites map, the ability to decouple your functions from one another and create a bounded context around each one will make your microservices deploy quicker. Designing your microservices in such a way that they align with business capabilities allows for independent management, versioning, maintenance and enhancement. 

7. Coming to terms with eventual consistency

Microservices are, by definition, vertical slices of capability that extend all the way to the data layer. However, this means that microservice A may have data that microservice B requires. Even if microservice B has the data, it may be stale as each service is not working on the same copy of data as they are independent. Designing your system in such a way that allows for user data to be eventually consistent breaks the need for hard requirements on things like dependencies and transactions.

8. Preparing for increased failover/monitoring/logging capabilities

How successful are you today in handling disaster recovery for your monolith? How easy is it to debug a problem in production? What happens to your performance at various peak hours? Any answers here would need to change considerably with microservices. You may need to monitor many capabilities/microservices at once. You may need to track a user flow through multiple services. A single microservice (or potentially multiples) may be at fault for performance issues. The infrastructure and process around support is vital. 

 

The ability for organizations to change not only the technology but the design, process and understanding will be the most successful with microservices.

This post has not been tagged.

Share |
PermalinkComments (0)
 

Why Should I Choose a Microservices Architecture??

Posted By Phil Helm, Wednesday, August 3, 2016

(This blog post is one in a series that will give you some insight into the full day training class (Microservices Solution Architectures) I will be teaching at the ITARC Austin on October 6th, 2016. )

That's a great question. Maybe you shouldn't. I have had this debate with more than one person:

"Isn't a microservices architecture just another iteration of SOA?"

In a way, it is. SOA is a natural offspring of distributed computing, which had been (and still is) evolving.

 Service orientation purports to be a way to expose data and/or capabilities via "services". A service can be exposed in a number of ways, however the prevailing methodology at SOA's inception was to use SOAP/XML behind an ESB. REST had not come to fruition, and neither had JSON. Heavy canonical models and WSDLs had not yet given way to consumer contracts and API interfaces. Waterfall still ruled the SDLC world. Monolithic applications and multi-month release cycles were the norm. 

Even Wikipedia, in it's definition, talks specifically about these types of technologies.

Here are some of the differences between SOA and Microservices, in my opinion:

1. SOA architecture describes horizontal slices (ie, the Monolith). Microservices are vertical slices.

2. For better or worse, in many eyes, SOA is tied to the technologies/SDLC available at the time of it's heyday. Microservices support polyglot and most closely related to modern delivery techniques like DevOps/Cloud First.

3. Microservices intend to be individual entities owned and managed by separate (and potentially disparate) teams. 

4. SOA is a model where the services are reused. Microservices do not place any emphasis on this; in fact it's focus on bounded context implies the opposite.

5. SOA is traditionally transaction based. Microservices focuses more on eventual consistency.

The similarities, however, cannot be ignored. They are both service based architectures. They should be a "black box" to the consumer. Contracts are a must. They are remotely accessible.

Ok, enough about SOA vs. Microservices. You can Google it and find more information than you care to read on this topic. So, why should you choose a Microservices architecture? The best reasons to do so, I believe, have to do with how the implementations (I intentionally made that plural, think about it) fit into the way we as architects create a business case and/or business value. We need to be able to deliver new and enhanced capabilities at a breakneck pace. We need to account for the consumption of those capabilities to be distributed and different. We need to scale, but do it efficiently. We need to take advantage of the skills of large teams, regardless of their location. We need to manage complexity. These needs are much better served by implementing a Microservices architecture. Yes, there are a host of new problems that need to be addressed (failure tolerance, operational changes and consistency are my top three) - and a major culture change needs to be absorbed by any adopters - however I believe being able to tell the CTO "Hey, that capability you asked us to enhance? We just pushed it to production in three hours" is an extremely powerful way to make yourself a partner with business, and not just a cost center.

Now... has anyone heard of containers? :) 

Tags:  microservices monolith architecture modular 

Share |
PermalinkComments (0)
 

Debugging a container that won't start

Posted By Phil Helm, Friday, July 22, 2016

This blog post is the first in a series that will give you some insight into the full day training class (Microservice Solution Architectures) I will be teaching at the ITARC Austin on October 6th, 2016

 

To implement an architecture that takes advantage of container technology, one way to persist the data has been to use a separate data container. In my case, I am using Jenkins in a container, and I want to save the configuration/jobs/history from my CI flow. Ideally, this container would a part of some kind of DR process, but in my case I simply wanted to show that the primary (jenkins process) container was disposable without the need to rebuild jobs.

During my most recent (of many) laptop restart, I noticed my jenkins data had disappeared. Actually, what I noticed was that there was a dummy "test" job that I had created as part of a previous attempt at building out Jenkins jobs. I wasnt sure why this suddenly happened, so I started debugging. I tried starting the data container (which I later realized did not need to be started in the first place) and it immediately failed and stopped. Although I can now move on to figure out why my data container is not working with my primary container,  I went through some debugging steps that I thought may be of use to some.

1. Find out if the Docker daemon is running

Since I am running on Ubuntu, I built this VM to use Upstart as the boot time start mechanism. This means I need to use it's utilities to check the status:

> sudo status docker 

docker start/running, process 2841

so far so good.

2. Start your container, see if it's running.

> sudo docker start xxx (where 'xxx' are there first 3 characters of the docker container)

> sudo docker ps 

When I did this, nothing was listed..

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

jenkinsadmin@ubuntu:~/jenkins-data$

so that tells me the container didnt start correctly. Then I did a

> sudo docker ps -a

now i see my container:

CONTAINER ID        IMAGE                     COMMAND                   CREATED              STATUS                                   PORTS               NAMES

6a721ae2d232        myjenkinsdata       "echo 'Data container"   4 weeks ago         Exited (0) About an hour ago                           jenkins-data

under the STATUS column, I see it is "Exited". Not good. 

3. Check the container log

> sudo docker logs xxx

where 'xxx' are the first three characters of the container. This should show you any message output during container initialization. In my case, it was

jenkinsadmin@ubuntu:~$ sudo docker logs 6a7

[sudo] password for jenkinsadmin: 

Data container for Jenkins

this "data container for jenkins" message corresponds to the final entry in my Dockerfile, 

CMD ["echo", "Data container for Jenkins"]

that at least told me the commands in the Dockerfile were executing.

4. Commit the container changes to a new image

The idea here is that if there is corruption in the container, you can determine whether the image itself is also at fault by committing the changes (to a new image) and creating a new container from that new image.

>docker commit --change "debug container vs image" xxxxxxxxx /: where 'xxxxxxxxxxx' is the container id. 

now you can execute the "docker run" command (as you did originally to create the container you are trying to debug)

 

If you want more information, follow the Iasa Raleigh blog, and sign up for my Microservices Solution Architectures class at the Austin ITARC!

 




 

 

Tags:  microservices containers docker jenkins data conti 

Share |
PermalinkComments (0)
 

Iasa Docker Workshop @ Lexis Nexis

Posted By Phil Helm, Wednesday, March 9, 2016

Thanks to all that attended the Iasa Docker Workshop on 3/8/16, hosted by our chapter partners, Lexis Nexis! Dr. Parnin has run this workshop a few times now and certainly has a cadence and rhythm now. We enjoyed this workshop at MetLife a few weeks ago, and it was great to spread out and partner with Kevin Kelly and the staff at Lexis Nexis. We appreciate the partnership and hope to have future events there!

I have posted a few pictures of the event in the Raleigh photo album here:

http://members.iasaglobal.org/gallery/ViewAlbum.aspx?group=151326&album=

 Our next event will be the API problem solver. Hope to see you there!

This post has not been tagged.

Share |
PermalinkComments (0)
 

Iasa Raleigh Social Media

Posted By Phil Helm, Monday, January 18, 2016

All,

Iasa Raleigh has several social media outlets to communicate and share:

Facebook: https://www.facebook.com/Iasaraleigh/

Twitter: @iasa_raleigh

WhatsApp: Iasa Raleigh

LinkedIn: https://www.linkedin.com/groups/6980251

This post has not been tagged.

Share |
PermalinkComments (0)
 

Microservices and API Month at Iasa Global

Posted By Paul Preiss, Friday, October 2, 2015

Iasa Global is starting a new feature for the website and members. We have chosen this month as Microservices and API strategy month. We would like to ask you to contribute.

Blogs, Articles, Examples:

If you would like to submit a blog or article we will host it at www.iasaglobal.org. Please contact us at contactus@iasaglobal.org to submit. 

Speaking Opportunities:

We wanted to see if you would be interested in submitting a paper to speak at our October 21st e-summit on Microservices or APIs. The e-summit is an all day set of webinars held by key industry speakers for our membership. In past e-summits we’ve had over 700 attendees though the target is a more modest 200 or so. The sessions are 45 minutes plus questions and answers and preference in speakers will be given to case studies from practical application and/or best practices learned from actual deployments.

We already numerous possible speakers and we would be thrilled for you to submit a talk for consideration. Some the topics we are interested are:

Security in Microservices

Challenges of Microservices Architectures

Lessons from the Field

Business models for Microservices and APIs

Design patterns and antipatterns

Tool comparisons and techniques in Microservices and APIs

 

We are open to any topic you would like to suggest. If you are interested can you send us a brief writeup of your proposed topics. Selections will be made by the 2nd week in Oct. 

 

This post has not been tagged.

Share |
PermalinkComments (0)
 

Microservices and API Month at Iasa Global

Posted By Paul Preiss, Friday, October 2, 2015

Iasa Global is starting a new feature for the website and members. We have chosen this month as Microservices and API strategy month. We would like to ask you to contribute.

Blogs, Articles, Examples:

If you would like to submit a blog or article we will host it at www.iasaglobal.org. Please contact us at contactus@iasaglobal.org to submit. 

Speaking Opportunities:

We wanted to see if you would be interested in submitting a paper to speak at our October 21st e-summit on Microservices or APIs. The e-summit is an all day set of webinars held by key industry speakers for our membership. In past e-summits we’ve had over 700 attendees though the target is a more modest 200 or so. The sessions are 45 minutes plus questions and answers and preference in speakers will be given to case studies from practical application and/or best practices learned from actual deployments.

We already numerous possible speakers and we would be thrilled for you to submit a talk for consideration. Some the topics we are interested are:

Security in Microservices

Challenges of Microservices Architectures

Lessons from the Field

Business models for Microservices and APIs

Design patterns and antipatterns

Tool comparisons and techniques in Microservices and APIs

 

We are open to any topic you would like to suggest. If you are interested can you send us a brief writeup of your proposed topics. Selections will be made by the 2nd week in Oct. 

 

This post has not been tagged.

Share |
PermalinkComments (0)
 

API’s are all the rage. But do we all agree on what they are and why they are relevant today?

Posted By Matthew Showers, Friday, August 7, 2015

API is an acronym that has been around for years and yet has a ton of buzz in the IT industry today. But do we as IT professionals all agree on what an API is and why we need them? We want your input so please share your opinions with us here on the following:

·         What is an API and why are they all the rage in the industry today?

·         What is API Management and why do we need it?

·         Are API’s part of SOA? Or do they replace SOA?

·         How are you personally using APIs to bring value to your organization.

 Looking forward to the conversation!

 

And don't forget to join us at our inaugural event August 13th 2015, at 5:30pm at the NC State University’s Jane S. McKimmon Conference Center. The chapter leadership team will introduce the chapter vision and planned programs and activities followed by keynotes from  Alex Seidita, Senior Vice President & Chief Technology Architect at MetLife; and Paul Preiss, CEO at Iasa Global followed by an API Strategy panel discussion.

Tags:  api  SOA 

Share |
PermalinkComments (2)
 
more Calendar

The upcoming calendar is currently empty.

Click here to view past events and photos »

Featured Members
Madhukar RajagopalIndustry Expert

Association Management Software Powered by YourMembership  ::  Legal