Nathaniel Schutta

Development teams often focus on getting code to production losing site of what comes after the design and build phase. But we must consider the full life cycle of our systems from inception to deployment through to sunset, a discipline many companies refer to as site reliability engineering.

While your organization may or may not have an SRE team, you have someone playing that role and we can all benefit from looking at the principles and practices that we can bring to bear on our projects. In this talk, I will introduce the concepts of SRE and how you can adopt these ideas on your applications.

Software architecture is having a moment, from best selling books to packed classes, the software industry acknowledges the importance of the parts of software resistant to internet searches. Ample pixels have been spilt talking about patterns, decomposition, styles, diagrams and more and all to good ends!

When it is time to review an architecture, what should you do? What factors should you consider? How do provide constructive feedback? We won’t just talk theory, we’ll work through real world examples, providing you chance to practice this vital skill.

By now your organization has planted a flag in “the Cloud” and it up to you to figure out just what that means to your application portfolio. Should everything be a microservice? Wait, what is a microservices anyway? How do you deal with massively distributed applications? How can event storming fix the gap between your business problems and domain model?

In this workshop, you will take a kata from event storming through to an initial design stopping along the way to discuss:

• Cloud native culture
• Domain driven design
• The importance of paved roads
• Chaos engineering
• Production Hardened Services

By now your organization has planted a flag in “the Cloud” and it is up to you to figure out just what that means to your application portfolio. Should everything be a microservice? Wait, what is a microservices anyway? How do you deal with massively distributed applications? What do you do with your legacy portfolio? In this presentation, we will walk through how the cloud impacts are applications and what we can do to successfully move our organizations forward.

By now your organization has planted a flag in “the Cloud” and it is up to you to figure out just what that means to your application portfolio. Should everything be a microservice? Wait, what is a microservices anyway? How do you deal with massively distributed applications? What do you do with your legacy portfolio? In this presentation, we will walk through how the cloud impacts are applications and what we can do to successfully move our organizations forward.

Software development has changed dramatically in recent years; no longer can you afford to say, “That’s how we’ve always done it.” Applications are evolving rapidly, which requires you to move fast and fix things. And don’t neglect the cultural shift inherent in any technical change. (Some developers, for instance, reject build-break notifications, going so far as removing themselves from the email list.)

If you’re just starting your CI/CD journey, you must ensure everyone understands the benefits, including increased speed-to-market, stable builds, and reduced drama around releases. That way, CI/CD won’t just help you deliver for your customers—it will help you sleep better at night.

The shift to cloud computing involves a veritable plethora of new technologies and approaches. From 12 factors to domain drive design change is afoot. Your organization is knee deep in functions and platforms and containers and while the technology is important, we can’t afford to overlook the importance of culture. What changes when we go to the cloud? How do we get there? How does Conways law affect the success of our efforts? How can we help people navigate the latest evolution in computing?

This talk will explore how cloud native computing impacts more than just our architecture.

Becoming a software architect is a longed-for career upgrade for many software developers. While the job title suggests a work day focused on technical decision-making, the reality is quite different. In this workshop, software architect Nathaniel Schutta constructs a real world job description in which communication trumps coding.

Discover the skill sets needed to juggle multiple priorities, meetings, and time demandsLearn why your best team leadership tool is not a hammer, but a shared cup of coffeeHear the best ways to give and take criticismUnderstand the necessity of writing effective email and formal architecture documentsGet tips for delivering confident career-building presentations to any audienceReview essential techniques for stakeholder management and relationship buildingExplore the critical needs for architecture reviews and an effective process for conducting themThrough lecture and small group exercises, Nathaniel will help you understand what it means to be a successful architect. Working through various problems, attendees will have opportunities to think through architectural decisions and patterns, discuss the importance of non functional requirements and why architects cannot afford to practice resume driven design.

Every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But your application portfolio is full of “heritage” systems that hail from the time before everything was as a service. Not all of those applications will make it to the valley beyond, how do you grapple with your legacy portfolio? This talk will explore the strategies, tools and techniques you can apply as you evolve towards a cloud native future.

In this talk, you will learn:

• how to evaluate your legacy applications
• how to take those heritage systems to the Cloud
• what 12 Factors means for you
• where it makes sense to use microservices
• what tools and services you'll need to add to your repertoire

In some organizations, architects are dismissed as people that draw box and arrow diagrams - the dreaded whiteboard architect. While we don't want to foster that stereotype, it is important for an architect to be able to construct basic architectural diagrams. An architect must also be able to separate the wheat from the chaff eliminating those models that don't help tell the story while fully leveraging those that do.

In this workshop, we'll discuss the various diagrams at our disposal. We'll walk through a case study and as we go, we'll construct a set of diagrams that will help us effectively communicate our design. We'll talk about stakeholders and who might benefit from each typ of diagram. Additionally we'll discuss how to constructively review an architectural model.

As we migrate towards distributed applications, it is more than just our architectures that are changing, so too are the structures of our teams. The Inverse Conway Maneuver tells us small, autonomous teams are needed to produce small, autonomous services. Architects are spread thin and can’t be involved with every decision. Today, we must empower our teams but we need to ensure our teams are making good choices. How do we do that? How do you put together a cohesive architecture around distributed teams?

This talk will discuss creating “paved roads”, well worn paths that we know works and we can support. We will also explore the importance of fitness functions to help our teams adopt appropriate designs.

By now I bet your company has hundreds, maybe thousands of services, heck you might even consider some of them micro is stature! And while many organizations have plowed headlong down this particular architectural path, your spidey sense might be tingling…how do we keep this ecosystem healthy?

In this talk, I will go beyond the buzzwords into the nitty gritty of actually succeeding with a service based architecture. We will cover the principles and practices that will make sure your systems are stable and resilient while allowing you to get a decent night's sleep!

These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.

There are many good reasons to use a microservices architecture. But there are no free lunches. The positives of microservices come with added complexity. Teams should happily take on that complexity…provided the application in question benefits from the upside of microservices. This talk will cut through the hype to help you make the right choice for your unique situation.

If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.

In this talk, I will explore what criteria we should consider when comparing technologies, how we can avoid burning platforms as well as what to do when we’ve reached a dead end. We will also apply these techniques to a current technology or two.

With globally distributed applications (and teams!) the job of software architect isn’t getting any easier; applications are growing increasingly complex and architects are spread thin. You can’t be involved with every decision, you must empower your teams while ensuring they are making good choices. How do you do that? How can frameworks like Spring not only make your life easier but help your teams deliver robust applications to production? Spring Cloud has a veritable plethora of sub projects from circuit breakers to functions simplifying the task of building cloud native applications while making it easy for developers to adhere to best practices. At the same time it can be overwhelming to get your head wrapped around all the features Spring offers. This talk will show how Spring allows architects to focus on the critical design decisions they need to make while ensuring developers are empowered to implement critical business use cases. Today’s cloud native applications have similar pitfalls, luckily Spring is here to help you resolve them!

This talk will show how Spring allows architects to focus on the critical design decisions they need to make while ensuring developers are empowered to implement critical business use cases. Today’s cloud native applications have similar pitfalls, luckily Spring is here to help you resolve them!

These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.

Microservices demand more than just a new architecture, they require a cultural shift. In this workshop, we'll cover:

• A set of principles that will help you decide if microservices are the best choice for your applications
• How to build production-hardened services
• How to empower your teams while ensuring they make good decisions
• How to develop a cloud native culture
• The challenges and pitfalls of microservice architectures and how to manage them

Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs?

As architects it is our responsibility to effectively guide our teams on the technology journey. In this talk I will outline the importance of trade offs, how we can analyze new technologies and how we can effectively capture the inevitable architectural decisions we will make. I will also explore the value of fitness functions as a way of ensuring the decisions we make are actually reflected in the code base.