integration

HashiCorp

5 Essential Software Architecture Podcasts 2019

Functional Programming

В этот раз мы решили углубиться в конкретную технологию - GraphQL. В этом нам помог Стеценко Макар из Silicon Valley Insight, который выступал с аналогичной темой на последнем MBLT! Что не хватает REST и подходит ли GraphQL для домашних проектов? Обо всем об этом в 32 выпуске подлодки!

Поддержи лучший подкаст про мобильную разработку: www.patreon.com/podlodka

Также ждем вас, ваши лайки, репосты и комменты в мессенджерах и соцсетях!  Telegram-чат: t.me/podlodka  Страница в Facebook: www.facebook.com/podlodkacast/  Twitter-аккаунт: twitter.com/PodlodkaPodcast

Содержание: 
- 00:00:30 - Знакомство с гостем
- 00:04:45 - Как прийти к GraphQL
- 00:15:45 - Что такое GraphQL
- 00:25:00 - Сравнение с REST
- 00:46:00 - GraphQL как множество данных
- 01:34:00 - Resolve-функции и их тестирование
- 01:41:30 - Оптимизация запросов
- 02:03:00 - Как продать GraphQL своей команде

Полезные ссылки: 

Подбор выходного дня
https://medium.com/@StetsenkoMakar/graphql-starter-pack-fcc48f5d14b9

 Вот тут кратко и ясно про место GraphQL в стеке. То что говорил Стас про фасад, называется GraphQL Gateway, то что я называл GraphQL first уже обозвали GraphQL Native. Как обычно, гибридный подход побеждает
https://blog.graph.cool/graphql-api-gateway-graphql-native-1e46e4f179f7 

Интересный набор визаулизаций и немного объяснений, как работает нормализированный кеш в Аполло
 https://dev-blog.apollodata.com/the-concepts-of-graphql-bc68bd819be3 

Интересный инструмент, который создает GraphQL схему на основе существующей PostgreSQL базы
https://github.com/postgraphql/postgraphql  

Краткие конспекты с GraphQL Summit 2017, много интересного и про будущее
https://about.sourcegraph.com/graphql

Podlodka #32 - GraphQL

In this episode we talk to Mitchell Hashimoto, founder and co-CTO of HashiCorp and Paul Banks, software engineer on the Consul team.

We get a little insight into the personalities and backgrounds of both guests, most importantly we learn some amazing things about the new feature in Consul called Connect.  Why we need a Service Mesh and how it helps with security for dynamically scheduled and legacy applications.

https://www.consul.io

Episode 6 - Consul Connect With Mitchell Hashimoto And Paul Banks

On today’s podcast, Justin Cormack discusses how the modern operating system is being decomposed with toolkits and libraries such as LinuxKit, eBPF, XDP, and what the kernel space service mesh Cilium is doing. Wes Reisz and Justin Cormack also discuss how Cilium differs from service meshes like an Istio, Linkerd2 (previously Conduit), or Envoy. Justin is a systems engineer at Docker. He previously was working with unikernels at Unikernel Systems in Cambridge before being acquired by Docker. (edited)

*Key Takeaways:*
* LinuxKit is an appliance way of thinking about your operating system and is gaining adoption. There are contributions now from Oracle, Cloudflare, Intel, etc. Docker has seen interesting use cases such as customers running LinuxKit on large cloud providers directly on bare metal (more on this coming soon).
* The operating system of today is really unchanged since the Sun workstation of the 90’s. Yet everything else about software has really changed such as automation, build pipelines, and delivery.
* XDP (eXpress Data Path) is a packet processing layer for Linux that lets you run fast in kernel compiled safe program in kernel called eBPF. It’s used for things like packet filtering and encapsulation/decapsulation.
* Cilium is an in-kernel, high performance service mesh that leverages eBPF. Cilium is very good at layer 4 processing, but doesn’t really do the layer 7 things that some of the other services meshes can offer (such as proxying http/1 to http/2)

Justin Cormack on Decomposing the Modern Operating System

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

InfoQ Podcast

Show Notes

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

In June of this year, Consul 1.2 was released. The release expanded Consul’s capability around service segmentation (controlling who and how services connect East and West). On this week’s podcast, Wes and Mitchell discuss Consul in detail. The two discuss Consul’s design decisions around focusing on user space networking, layer 4 routing, Go, Windows’ performance characteristics, the roadmap for eBPF on Linux, and an interesting feature that Consul implements called Network Tomography. The show wraps with Mitchell’s discussion on some of the research that Hashicorp is doing around machine learning and security with Consul.

Why listen to this podcast:

- Consul is first and foremost a centralized service registry that provides discovery. While it has a key-value store, it is Consul’s least important feature.
With the June release (1.2), Consul entered more into the space of a service mesh with the focus on service segmentation (controlling how you connect and who can connect).
- Hashicorp attempts to limit the language fragmentation in the Company and has seen a lot of success leveraging Go across their platforms. Therefore, Consul is written in Go.
- Because Consul focused on layer 4 first, it is recommended to leverage the recent integration with Envoy for achieving high degrees of observability.
- All of the network routing with Consul happens in user space at this point; however, kernel space routing with eBPF is planned for the near term. The focus, at this point, is safely cross-compiling to every platform and addressing the most possible use cases. The focuses isn’t on the high performance use cases (yet).
- For any two servers across the globe in different data centers, instantly Consul can give you 99th percentile round-trip time between with uses a feature called Network Tomography.

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

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/2S3ZiSx

Mitchell Hashimoto on Consul since 1.2 and its Role as a Modern Service Mesh

Martin Fowler chats about the work he’s done over the last couple of years on the rewrite of the original Refactorings book. He discusses how this thought process has changed and how that’s affected the new edition of the book. In addition to discussing Refactors, Martin and Wes discuss his thoughts on evolutionary architecture, team structures, and how the idea of refactors can be applied in larger architecture contexts.

Why listen to this podcast:

 -    Refactoring is the idea of trying to identify the sequence of small steps that allows you to make a big change. That core idea hasn’t changed.
 - Several new refactorings in the book deal with the idea of transforming data structures into other data structures, Combine Functions into Transform for example.
 - Several of the refactorings were removed or not added to the book in favor of adding them to a web edition of the book.
 - A lot of the early refactorings are like cleaning the dirt off the glass of a window. You just need them to be able to see where the hell you are and then you can start looking at the broader ones.
 - Refactorings can be applied broadly to architecture evolution. Two recent posts How to break a Monolith into Microservices, by Zhamak Dehghani,  and How to extract a data-rich service from a monolith by Praful Todkar on MartinFowler.com deal with this specifically.
 - Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example.

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

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/2QbdHej

Martin Fowler Discusses New Edition of Refactoring, Along With Thoughts on Evolutionary Architecture

For those who may not be aware, Mitchell Hashimoto is a Co-founder and CTO at HashiCorp where he directs the company’s vision, values, product design, and culture. Mitchell and his team have created several popular open source tools that have helped engineering teams automate their deployment process. He is best known for Vagrant, Consul, Packer, and Vault. Hashimoto majored in Computer Science at the University of Washington and is a recent newlywed. 

During his time at UW, he started his first popular open source project: Vagrant, that led him to cofound HashiCorp with his partner, Armon Dadgar. Mitchell and Armon are committed to delivering software tools to support next-generation technologies that will empower companies worldwide to re-engineer their workflows.

Learn To Trust Yourself in Life and Business with Mitchell Hashimoto

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

Software engineers, architects and team leads have found inspiration to drive change and innovation in their team by listening to the weekly InfoQ Podcast. They have received essential information that helped them validate their software development map. We have achieved that by interviewing some of the top CTOs, engineers and technology directors from companies like Uber, Netflix and more. Over 1,200,000 downloads in the last 3 years.