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.
Responsible Microservices is based on my blog series Should that be a Microservice? Keep These Six Factors in Mind found on the Pivotal blog.
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:
By now, just about every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But there is a lot of confusion around cloud native, 12 factors, modular monoliths, serverless…how does a busy technologist make sense of it all? Despite what you may have read on the Internet, there still are no silver bullets - just a set of tools that we need to apply at the right time in the right place. In this talk we will survey the various options today’s application teams have at their disposal looking at the consequences of various approaches. We will clear up the buzzword bingo giving you a solid foundation as you take your cloud native journey.
Today our world is full of things that are “as a service” - infrastructure, containers, platforms, software…and of course functions. With developers just now wrapping their heads around application platforms and containers, what are they to make of functions as a service? How does a busy developer cut through the hype and make sense of the world of serverless, Kubernetes, Spring Cloud Function and all the rest? This talk will clear up the confusion! We examine Riff, a FaaS built atop Kubernetes. We will discuss where functions and serverless fits in your world, and how you can get started with some simple demos. Though functions aren’t a silver bullet, they are an important part of the development toolbox; this talk saves you from the buzzword bingo to give you a solid foundation of the FaaS landscape.
Software developers are seemingly on a perpetual path to discover the one true technology to unite them all. And yet there are no golden hammers, there is no one size fits all solutions. Instead we have to carefully weigh the pros and cons of our options and in some instances take the least worst approach. Rather than continue down this trail of disappointment, we need to embrace the and not the or. There can only be one does not in fact apply to software.
Nathaniel Schutta explains why an architect’s job is to be a storyteller. Architects are essentially the Rosetta Stone of an organization, providing translation services (or, as some would call it, the “elevator” between the executive suite and the development floors). The challenge lies in not only crafting a compelling message but doing so for wildly disparate audiences. (The pitch you give your developers will not go over well with the executives, for instance.) While we may not want to adopt iambic pentameter anytime soon (though who knows, that might encourage more people to read our various artifacts), we must consciously think about the story we are telling.
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.
As a developer, your focus was squarely on the “functional requirements” aka the business capabilities your application must meet. But once you step in the architect role, you discover a world inhabited by “the ilities” otherwise known as the non functional or quality attributes of a software system. But how do we know which ilities matter and which ones don’t? And much as we may want to turn every knob up to 11, many ilities are inversely related - maximize one and you by definition minimize another.
In this talk we will look at various architectural problems giving participants opportunities to try and balance non functional requirements. We’ll discuss the consequences of various approaches as well as how we can best document the inevitable decisions we arrive at.
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.
In this talk I will explore various options you can deploy on your projects to tame the mass of code that lives on the front end of our applications. From NPM to Gulp to Webpack, this talk will help you establish a front end pipeline.
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!
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.
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.