Nathaniel Schutta
ArchConf
Clearwater · December 10 - 13, 2018
Architect as a Service
Nathaniel T. Schutta is a software architect and Java Champion focused on cloud computing, developer happiness and building usable applications. A proponent of polyglot programming, Nate has written multiple books, appeared in countless videos and many podcasts. He’s also a seasoned speaker who regularly presents at worldwide conferences, No Fluff Just Stuff symposia, meetups, universities, and user groups. In addition to his day job, Nate is an adjunct professor at the University of Minnesota, where he teaches students to embrace (and evaluate) technical change. Driven to rid the world of bad presentations, he coauthored the book Presentation Patterns with Neal Ford and Matthew McCullough, and he also published Thinking Architecturally and Responsible Microservices available from O’Reilly. His latest book, Fundamentals of Software Engineering, is currently available in early release.
Presentations
Developer To Architect
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.
Functions and Platforms and Containers, Oh My!
Let me guess - your company is all in on “the Cloud” but no one can really agree what that means. You’ve got one group Dockering all the things while another group just rearchitected the Wombat system as a set of functions…as a service. It is enough to make a busy developer’s head spin - how do we make sense of all the options we have? I hate to burst your bubble, but there are no silver bullets, just a set of tools that we can leverage to solve problems. And just as a master carpenter knows when to use their favorite framing hammer and when they need to reach for the finish hammer, we need to use the right tool at the right time to solve our problems.
An Architect's Guide to Site Reliability Engineering
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.
Modeling for Architects
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.
Modeling for Architects
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.
Production Hardened Services
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?
Thinking Architecturally
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?
Production Hardened Services
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?