todo

This episode is a panel discussion from the microservices track QCon Plus, held in May 2021. Track host Nicki Watt asks "What have we learned over the last decade of microservices." The panelists included Chris Richardson, James Lewis, and Katie Gamanji. The discussion started with looking at how the meaning of "microservices architecture" has evolved over the past ten years. There were some great insights about how successfully developing, deploying, and maintaining software depends as much or more on cultural and environmental factors, than simply adopting microservices and all the tools and technology that now exist.

Read a transcript of this interview: https://bit.ly/3rOTrD7

Subscribe to our newsletters:
- The InfoQ weekly newsletter: bit.ly/24x3IVq
- The Software Architects’ Newsletter [monthly]: https://www.infoq.com/software-architects-newsletter/

Upcoming Virtual Events - https://events.infoq.com/

InfoQ Live:
https://live.infoq.com/
- August 17, 2021
- September 21, 2021
- October 19, 2021

QCon Plus online conference:
https://plus.qconferences.com/
- November 1-12, 2021

Follow InfoQ:
- Twitter: https://twitter.com/infoq
- LinkedIn: https://www.linkedin.com/company/infoq/
- Facebook: https://www.facebook.com/InfoQdotcom/
- Instagram: @infoqdotcom
- Youtube: https://www.youtube.com/infoq

InfoQ Podcast

Transcript

What Have We Learned Over the Last Decade of Microservices?

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Alex Qin following on from her QCon London talk “Shaving My Head Made Me A Better Programmer”.

Why listen to this podcast:

- Casual discrimination and unconscious bias is rife in society, and very prevalent in tech
 - The need to have many more people in the field who don’t fit the preconceived mould of a programmer
 - The complexity of the overall system means we need to tackle discrimination at many levels in many different aspects
 - One person can make a difference
 - Call things out when you see things that are wrong – speak up, show up and shield those who can’t shield themselves

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2ugjaZY

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2ugjaZY

Show Notes

Alex Qin on Leveraging Technology to Create Positive Social Change

Wes Reisz sits down and chats with Uncle Bob about The Clean Architecture, the origins of the Software Craftsperson Movement, Livable Code, and even ethics in software. Uncle Bob discusses his thoughts on how The Clean Architecture is affected by things like functional programming, services meshes, and microservices.

Why listen to this podcast:

* Michael Feathers wrote to Bob and said if you rearrange the order of the design principles, it spells SOLID.
* Software Craftsperson should be used when you talking about software craftsmanship in a gender-neutral way to steer clear of anything exclusionary.
* Clean Architecture is a way to develop software with low coupling and is independent of implementation details.
* Clean Architecture and Domain Driven Design (DDD) are compatible terms. You would find the ubiquitous language and bounded context of DDD at the innermost circles of a clean architecture.
* Services do not form an architecture. They form a deployment pattern that is a way of decoupling and therefore has no impact on the idea of clean architecture.
* There is room for “creature comforts” in a code base that makes for more livable, convenient code.
* “We have no ethics that are defined [in software].” If we don’t find a way to police it ourselves, governments will. We have to come up with a code of ethics.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Nebspj

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2Nebspj

Uncle Bob Martin on Clean Software, Craftsperson, Origins of SOLID, DDD, & Software Ethics

Vaughn Vernon is thought-leader in the space of reactive software and Domain Driven Design (DDD). Vaughn has recently released a new open source project called vlingo. The platform is designed to support DDD at the framework and toolkit level. On today’s podcast, Vaughn discusses what the framework is all about, why he felt it was needed, and some of the design decisions made in developing the platform, including things like the architecture, actor model decisions, clustering algorithm, and how DDD is realized with the framework.

Why listen to this podcast:

 - Vlingo is an open source system for building distributed, concurrent, event-driven, reactive microservices that supports (at the framework level) Domain Driven Design.
 - The platform is in the early stages. It runs on the JVM. There is a port to C#. All code is pushed up stream.
 - The platform uses the actor model and all messages are sent in a type-safe way.
 - Vlingo supports clustering and uses a bully algorithm to achieve consensus.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2MwEWxb

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2MwEWxb

Vaughn Vernon on Developing a Domain Driven Design first Actor-Based Microservices Framework

This week on the InfoQ Podcast, Wes Reisz talks to Tanya Reilly (Principal Engineer at Squarespace and previously a staff SRE at Google). Tanya discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters. This podcast features discussion on paved roads, prevention, testing, firefighting (in software), and reliability questions to ask throughout the software lifecycle.

Why listen to this podcast:

- Teams increasingly   are responsible for the entire software lifecycle. When this happens, they think about the software differently because they know their the ones that will get paged if it fails. This idea is at the core of the “You Build It, You Run It” philosophy in DevOps.
- The role of SRE is to define how to do things in a really reliable way. The focus is to make the majority of the operations work go away, and, for the things that can’t go away, it’s as easy as possible.
- At the very start of a project (when you’re writing the initial design), you should be thinking about the dependencies for a system and how will those that follow with be able to determine that. A great way to do this is to offer an API that people will want to use and then instrument it.
- We can learn a lot from the growth of fire safety regulations as metaphors for software, including: fireproof interior walls, socializing best practices, software inspections, and circuit breakers are all examples.
- The work SREs do varies in many places. SREs range from making recommendations on patterns to library creators in other areas. Occasionally, SREs are firefighters of last resort. In these cases, they’re the last resort though.
- We use error budgets and SLOs to quantify how many much risk we’re comfortable taking. It’s used to inform how much less (or more risk) we’re willing to take on.
- We need to consider software reliability throughout the full cycle of software development. When you build systems. Think about as if there will not be someone on call for it .

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq

Tanya Reilly on Site Reliability Engineering and the Evolution of the New York City Fire Code

On this podcast, Wes talks to John Xmas. Johnny works for Kasada, a company that offers a security platform to help ensure only your users are logging into your web applications. Johnny is a well-known figure in the security space. The two discuss common attack vectors, the OWASP Top 10, and then walk through what hackers commonly do attempting to compromise a system. The show is full of advice on protecting your systems including topics around Defense in Depth, Time-Based Security, two-factor authentication, logging/alerting, security layers, and much more.

Why listen to this podcast:

 - While there are sophisticated web attacks out there that use things like PhantomJS or Headless Chome, the vast majority of the web application attacks are the same unsophisticated scripted attacks that you always hear about. These are simple scripts using tools like curl and BurpSuite with Python or JavaScript. These simple scripts are still incredibly effective.
 - OWASP Top 10 really hasn’t changed all that much in the last ten years. For example, despite being the number one approach used to educate defensive engineers on how to protect their apps, SQLI (SQL Injection) is still the most common attack. We continue to repeat the same mistakes that have exposed systems for a decade now.
 - Phishing is by and far the quickest way to compromise a system. Defensive in Depth, security boundaries, limiting local admin rights are all things that corporations can implement to minimize the blast radius.
 - Attackers have hundreds of gigs of actual username/password combinations that have been exposed from all the breaches over the past few years. These are often a first step when attempting to compromise a system. It’s more often likely that they will figure out a valid email pattern for a company and then feed actual names into that pattern to go after the username. From there, brute force attacks with those usernames against libraries of passwords is a common approach.
 - A common approach is to go after an email login. While the email can be a treasure trove of information, it’s more about using those credentials in other places. It’s pretty common, for example, to use those credentials to get into a network with a VPN.
 - Captcha/reCaptcha is not very effective and preventing these brute force attacks. There are a large number of bypasses and even Mechanical Turk companies that are available to bypass these tools. What can be effective is Time Based Security because it slows the attackers down. If you can slow them down, you can make the attack say long to succeed that they’ll go somewhere else.
 - Once inside the network, most companies often have little security on internal systems. Multi-factor authentication, not just on the front door, but on internal systems is a huge step in the right direction. Monitoring not only for failed login attempts but, in some situations, valid login attempts (such as when a domain admin logs into a domain controller) should absolutely be used.
 - When it comes to application security between services within a network, the best advice is to make sure developers really understand what is trying to be accomplished by something like JWT (JSON Web Tokens). Often its the lack of understanding of what they’re actually doing that leads to system vulnerabilities.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2MSIAXG
You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2MSIAXG

Johnny Xmas on Web Security & the Anatomy of a Hack

In this Shane Hastie, Lead Editor for Culture & Methods, spoke to Pablo Santos of Plastic SCM about what it takes to create a great engineering culture, dealing with skills shortages, engaging remote workers and getting the highest value out of DevOps.    

Why listen to this podcast:

•	Attracting the right people is a constant challenge in the technology space
•	Having interesting and challenging work is important
•	Remote workers are common today and it’s important to focus on keeping them engaged
•	DevOps is a way to create a continuous flow of stable changes and get them into production quickly
•	The art of splitting the work is key to DevOps and it is something that takes significant understanding and careful design

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2ZZhAYn
You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2ZZhAYn

Pablo Santos on Creating a Great Engineering Culture, Engaging Remote Workers and DevOps

Software engineers, architects and team leads have found inspiration to build better, high performing teams by listening to the weekly InfoQ Podcast. We have achieved that by interviewing some of the top CTOs, engineers and technology directors from companies like Uber, Netflix and more. Over 500,000 downloads in the last 3 years.

Pablo Santos on Creating a Great Engineering Culture, Engaging Remote Workers and DevOps

Engineering Culture by InfoQ

Related tracks