SEI Insights


SEI Architecture Technology User Network (SATURN) News and Updates

Continuous software evolution and delivery refers to the organizational capability to innovate and release software in fast parallel cycles, typically hours, days, or very small numbers of weeks. This requires not only adoption of more agile processes in development teams or large investments in automated release pipelines, but changes in potentially the entire research and development organization in terms of technology and practices. Furthermore, automatic live monitoring and experimentation of different system alternatives enables fast evaluation and decision making. Finally, best practices and success stories should be documented and exchanged.

The Workshop on Continuous Software Evolution and Delivery (CSED), which grew out of the successful RELENG and RCoSE workshops, aims to bring together the research communities of the aforementioned areas to exchange challenges, ideas, and solutions to bring continuous software evolution and delivery a step further to being a holistic continuous process. The workshop will be run in a highly interactive manner to stimulate discussions, featuring presentations of practitioner abstracts and academic papers, as well as break-out groups focusing on lively interactions to identify challenges, existing approaches and potential directions for solutions.

For more information, see the CSED website.

Defining Microservices

By on

I see microservices as an architectural pattern or style. Some styles are well described in the literature (Roy Fielding's description of REST is an example). Unfortunately, there was no clear description of the microservices style when it became popular. And the growing buzz has contributed to the confusion because different people try to add nice-to-have characteristics to what a microservice should be. For example, based on things I've read, one might conclude that microservices should:

  • Have few lines of code (some say 10-100 LOC).
  • Not be part of circular calls across services.
  • Be developed by a team that can be fed by 1 or 2 pizzas.
  • Avoid synchronous communication (request-response calls).
  • Offer coarse-grained operations (though microservices are "fine-grained services").
  • Be run by the team who built them.
  • Not participate in complex service compositions.
  • Have the freedom to use new languages, frameworks, platforms at will.
  • Manage their own databases.
  • Be monitored by sophisticated logging and monitoring infrastructure.
  • Be developed by teams split around business capabilities motivated by Conway's law.
  • Match DDD bounded contexts.
  • Be dynamically discovered.
  • Be small enough to be rewritten in two weeks.

Thus, requirements for a microservice are all over the place, and often mention good software engineering practices known for decades.

I'd rather stick with the well-known description by Lewis and Fowler: "the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. "

From an architecture perspective, the microservice style belongs primarily to the deployment view. It dictates that the deployment unit should contain only one service or just a few cohesive services. The deployment constraint is the distinguishing factor. As a result, microservices are easier to deploy, become more scalable, and can be developed more independently by different teams using different technologies. Beyond that constraint, other characteristics describe a lean SOA service that does not use orchestration or ESB.

Despite the lack of clarity about what microservices really are, it's exciting to see the many ideas, tools, and discussion sprung from them. I'm not sure we're past the peak of inflated expectations with microservices, but I certainly look forward to seeing what consolidated shape microservices will have when they reach the plateau of productivity. At the moment, for us software developers, more important than having a clear definition is to understand the tradeoffs of using microservices.

Microservices is one of those buzzwords that generate a lot of hype but is ill defined. In another post, I comment about defining microservices. In this post, my main goal is to discuss pros and cons of using microservices in contrast with the monolithic approach, so let's cut to the chase.

What you gain and what you lose

Benefits of using microservices:

  • Deployability: more agility to roll out new versions of a service due to shorter build+test+deploy cycles. Also, flexibility to employ service-specific security, replication, persistence, and monitoring configurations.
  • Reliability: a microservice fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith.
  • Availability: rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith.
  • Scalability: each microservice can be scaled independently using pools, clusters, grids. The deployment characteristics make microservices a great match for the elasticity of the cloud.
  • Modifiability: more flexibility to use new frameworks, libraries, datasources, and other resources. Also, microservices are loosely-coupled, modular components only accessible via their contracts, and hence less prone to turn into a big ball of mud. Dynamic discovery and binding via a registry (e.g., Apache ZooKeeper, Netflix Eureka) is sometimes used for location transparency.
  • Management: the application development effort is divided across teams that are smaller and work more independently.

Challenges of using microservices:

  • Deployability: deployment becomes more complex with many jobs, scripts, transfer areas, and config files for deployment.
  • Performance: services more likely need to communicate over the network, whereas services within the monolith may benefit from local calls. Also, if the microservice uses dynamic discovery, the registry lookup is a performance overhead.
  • Availability: if you use a registry for dynamic discovery, unavailability of the registry may compromise the consumer-service interaction.
  • Modifiability: changes to the contract are more likely to impact consumers deployed elsewhere, whereas in the monolithic model consumers are more likely to be within the monolith and will be rolled out in lockstep with the service. Also, mechanisms to improve autonomy, such as eventual consistency and asynchronous calls, add complexity to microservices.
  • Testability: automated tests are harder to setup and run because they may span different microservices on different runtime environments.
  • Management: the application operation effort increases because there are more runtime components, log files, and point-to-point interactions to oversee.
  • Memory use: several classes and libraries are often replicated in each microservice bundle and the overall memory footprint increases.

What about autonomy?

Much of what I read about microservices mentions autonomy as a benefit. For example, Sam Newman's Building Microservices book says increased autonomy is a huge advantage of microservice architecture. But what is autonomy? And why didn't I list it in the pros of microservices above (or the cons either)?

First off, there's design autonomy: how much freedom you have to design, implement, and modify a software element. But more important to our discussion is runtime autonomy: how much control a component has over everything that is executed when the component is invoked. A service that doesn't need to interact with any other components outside its boundary is highly autonomous. If a service calls another service, accesses a shared database, sends a message or event to a message broker, then it loses a little bit of autonomy. A design goal is not to get rid of these kinds of interactions, but to avoid problematic ones so that the level of service autonomy doesn't compromise performance or reliability.

And what about the autonomy of microservices? They certainly beget high degrees of design autonomy--the team can employ different technologies and patterns to design and implement each microservice, and can change and redeploy each microservice independently. On the other side, services within a monolith often have to follow the same design constraints and change+deploy cycles--less design autonomy.

As for runtime autonomy, I'm afraid the very idea of microservices goes in the other direction. We're splitting the monolith into small distributed services. The overall business logic that was once collocated in the monolith is now spread across microservices. It's more likely that a microservice will interact with other microservices over the network--that interaction decreases autonomy. If the interaction between microservices involves changing data, the need for a transactional boundary further compromises autonomy. To quote Newman, "Don't also be surprised if things like distributed transactions or CAP theorem start giving you headaches."

The good news is that much of the schooling about microservices I've seen emphasizes this apprehension with autonomy. To avoid autonomy issues, the experts advise you to employ techniques such as eventual consistency, event-driven architecture, CQRS, cache (data replication), and aligning microservices with DDD bounded contexts. My point is that these great techniques are not inherent to microservices, but are desirable to prevent service autonomy issues that are inherent to microservices.

Researchers at the Carnegie Mellon University Software Engineering Institute are seeking volunteers to participate in a study. The Quantifying Uncertainty for Early Lifecycle Cost Estimation research project is conducting a public call for participation from individuals who have recent experience executing a Department of Defense (DoD) program. This study explores how to calibrate individual and group expert judgment in the context of decisions about uncertain events within DoD programs. The study also explores the impact of those uncertain events on the cost of executing a program.

The call for participation is open now through November 30, 2015. Participants will gain knowledge of measuring expert judgment and techniques to improve their own judgments and estimations. After the experiment, participants will receive their personal test results in addition to summarized group results in a format that maintains individual confidentiality.

The experiments will be conducted across two half-days of remote participation. For more information about the experiment and to volunteer, visit

With the emergence of an increasing number of conferences and professional-development opportunities in the field of software architecture, how is SATURN unique? Why should a software engineer choose to attend SATURN 2016?

SATURN is an annual gathering of software developers, architects, and thought leaders. At SATURN 2015 last April, 80% of the attendees had 10 or more years of experience and 56% were in leadership positions in their organizations. They gather to share experiences and ideas.

The relative experience of the SATURN community makes it uniquely qualified to evaluate the efficacy and practical utility of technology trends such as service-oriented architecture (SOA), microservices, and Internet of Things in a balanced way, avoiding reflexive promotion or advocacy.

"SATURN is about keeping the tribal history of software architecture and disseminating the fundamentals beyond current skills needed," says Len Bass, formerly of the SEI and of National Information and Communications Technology Australia (NICTA). "You will always want to know about the latest tools and the hottest methods, but more importantly, you will want to understand how to recognize the underlying concepts the next time a tool or method climbs the technology hype-cycle curve."

Such architectural knowledge building at SATURN provides learning and networking opportunities that have lasting value, greater than simply becoming familiar with the latest hot technical buzzwords.

The large number of experienced and technically savvy attendees at SATURN also affords junior developers or aspiring software architects the opportunity to network and learn from those with more experience, gain a solid understanding of techniques and methods that have been validated and proven to be effective, and find solutions to problems that others have solved in similar contexts. Knowledge sharing at SATURN happens through participatory sessions, tutorials, and open office hours with the creators of foundational techniques and methods.

SATURN has also evolved to be a conference where experience and research come together to forge new solutions to pressing problems, as a forum for articulating and exploring new ideas and leading-edge thinking. For example,

  • While software architecture training is now common in many global organizations, early adopters at SATURN began taking seminal software architecture courses from the SEI and others and sharing ideas, curricula, and experiences about developing software architectures in their own organizations.
  • Long before the coexistence of agile and architecture practices became a frequent topic of discussion in other technical venues, SATURN attendees were sharing their experiences and techniques for achieving agility at scale.

"We want SATURN to be thought of as the birthplace of new ideas and innovations in architecture-design practice," says Amine Chigani of GE Digital, a technical co-chair of SATURN 2016. If you are doing something new and interesting that you have successfully applied in a practical setting and that seems promising--even if it hasn't been proven yet--we want to hear about it.

Here are some examples of talks at SATURN conferences during the past few years that exemplify SATURN's balance of proven experience and new ideas that propel the discipline forward:

Proven experience:

New ideas:


The DEV@SATURN (Design, Engineering, Vision) talks that we have added to the SATURN technical program this year are intended to reinforce the vision of SATURN as a forum for sharing experience-based insights and articulating new ideas and innovations. Patterned after the popular TED series of talks, DEV@SATURN talks will be short, concentrated bursts of experience, wisdom, and inspiration.

We seek talks that are

  • Visionary - They open a window that reveals or makes visible the future of software design or report on a breakthrough to a new idea or new solution to what had been an intractable problem.
  • Passionate - They are delivered by a speaker with a passionate commitment and need to share a paradigm-changing idea or insight.
  • Concrete - They tell specific stories about something that the speaker has done, such as an idea or lesson realized in the course of a project, a big problem and why it is important, a report of a personal journey that led to an insight or breakthrough, or something that everyone thought was impossible until the speaker discovered otherwise.

Please consider submitting a proposal for a DEV@SATURN or a longer talk, and if you have never attended SATURN before, please join our growing community and attend SATURN 2016.

A DEV(Design, Engineering, Vision)@SATURN talk is similar to a TED talk and concisely shares a single breakthrough technique, lesson, or experience in a passionate and inspiring way. We have a few slots available for these presentations at SATURN 2016.

DEV@SATURN talks will be particularly story based with lots of colorful images, simple charts, videos, and other visual props. They will be short: you have a maximum of 15 minutes, which will force you to focus on only what matters. Speaker delivery is critical; audiences will react equally to the message and the messenger. It will help to watch a couple of TED talks to get a sense of the style. Remember, there will be a select few of these sessions in the technical program, so submit a proposal for this session type only if you believe you have the right topic and delivery style to delight your SATURN community.

Your DEV@SATURN talk will really ignite your audience when you focus on using stories and pictures. The 4D outline is a great tool to help you think about your purpose for each point and how you want to convey that point. With this tool, you can create an exciting presentation that drives home what you want your audience to remember.

We look forward to seeing your proposals!

The 12th SEI Architecture Technology User Network (SATURN) Conference 2016 will be held at the Sheraton San Diego Hotel & Marina in San Diego, California, May 2-5, 2016.

The SATURN 2016 Call for Submissions is now open.

Guest post by SATURN 2016 Program Committee Bett Correa, Architect at GE

So you are excited about presenting at SATURN 2016? Awesome!

One key question to ask is whether the audience will remember your presentation after the conference. There are a few tips I'd like to share that can help you give a memorable presentation.

When giving a presentation, focus on your audience and your purpose. Audience members may be saturated from having taken in so much information during the conference. You will leave a memorable impression on them only if you carefully construct your presentation. Grabbing their attention right from the beginning will help them realize that you are worth listening to. Make each slide purposeful. This might sound daunting but can be accomplished using a simple format I created called the 4D outline.

Before getting into the outline, define the following two items:

  1. Audience
  2. Purpose

The audience is just as important as the purpose--often people just have something to say and don't think about why they want to say it or to whom. Think of the difference between kindergarteners and software engineers. Take time to define these two items explicitly before moving on; doing so will greatly change how you create your presentation.

The example of a 4D outline shown below for an experience-report presentation demonstrates how such an outline forces you to think about each point and what you want to say.


Continue to create your outline for each section of your speech. Rather than filling your slides with long streams of text, find appropriate pictures/graphs for each section of your talk so that the audience has something to look at and doesn't have to read. Telling stories is an excellent way to keep your audience engaged. You can tell the same story over several slides.

The last few slides of your presentation should be the summary. This could be what you think the audience can take away and apply in their projects.

Once you have your presentation outline and slides put together, practice it between three to six times in front of others and alone to ensure that you know where on your slides you should make each point. While practicing you might find that you need to change slides around or change what you say on each. This is good! Keep making your presentation better and better. We strongly discourage you to rely too heavily on notes--doing so causes you to lose the essential connection with your audience that is so important to an effective presentation.

We hope you will follow the suggestions in this blog post and help us to make SATURN 2016 the best yet--good luck!

Bett Correa
Architect at GE

amine.pngAmine Chigani is a principal software architect at GE Digital. He leads the development of industrial internet-of-things (IoT) solutions for GE businesses and their customers in domains such as aviation, transportation, and energy. Amine is a founding member of the Industrial Internet Consortium's Architecture Working Group. Prior to his current assignment, Amine was an architect at GE Global Research, an architecture visiting scientist at the Software Engineering Institute (SEI), and CS adjunct faculty at Virginia Tech. Amine earned a PhD in Computer Science from Virginia Tech and the Software Architecture Professional Certificate from the SEI.

joe_olmheim.jpgJørn Ølmheim is a practicing software professional with strong beliefs in open source and internet technology. Currently he holds the position of leading advisor in corporate IT at Statoil, focusing on the subsurface application portfolio and systems integration challenges. He holds an MSc degree in computer science from the Norwegian University of Science and Technology (NTNU).

We welcome Amine and Jørn to the SATURN Technical Committee and look forward to working with them on SATURN 2016.

Bill Pollak
SATURN 2016 General Chair