What happens when you take a tech-driven online fashion company that's experiencing explosive growth and infuse it with a deep open-source mission?
Well, you'll find out on this episode of Talk Python to Me.
We'll meet Lori Apple and Rafael Carricio from Zalando, where developers there have published almost 200 open-source projects on GitHub.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem.
This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
Hey, everyone. Last episode, I told you about my crazy student reward for the Kickstarter.
Well, it turns out that Kickstarter is not super keen on us doing that.
I don't think we were violating the spirit of the rules, but we were actually violating the letter of the Kickstarter rules of conduct.
So sadly, we'll have to pull back that cool offer.
However, I'm replacing it with something that might even be better.
Instead of funding some of the businesses that successfully launch out of the course,
we'll have a special Talk Python to Me episode featuring and looking inside a couple of them.
Keep an eye out for that in six months or so.
Now, let's talk about fashionable open source code.
Lori, Raphael, welcome to the show.
Thanks.
It's good to be here.
Yeah, I'm really excited to talk to you guys about what's going on in Zalando.
It seems like you're doing a lot of cool Python things, and I think it'll be a fun story for the audience.
Yeah, I hope so.
Yeah, definitely.
All right, so both of you guys on the show.
So let's get started by talking about your background a little bit.
How did you get into software?
Lori, you want to go first?
Sure.
My name is Lori Apple, and I'm the open source evangelist in Zalando.
And I came into technology after law school.
So my background is not really in programming.
It's more in journalism.
I did some PR.
I also studied law.
And so right after law school, I started working in tech companies on and off.
And then in 2012, I started working at Gilt and became their technology evangelist.
So I was going to lots of meetups and running the tech blog and social media and working with developers to talk about what we were doing with engineering, with product, with UX.
And then I came to Zalando 2015, so last February.
And first I was doing technology evangelism.
And then my job kind of morphed into just focusing on the open source evangelism because we have so much work going on in the open source scene.
If you look at our dashboard, we have almost 200 projects.
And so there's lots to maintain.
And I'm also managing agile project managing a team.
So I guess I have two jobs here.
Yeah, that sounds really fun.
And you guys do have a lot going on.
We'll talk about some of your open source projects.
But, yeah, you pull that up and it's quite a list of stuff there.
Yeah, and there used to be a lot more.
But I will talk about why there isn't that much.
Oh, interesting.
Okay.
Yeah, cool.
Yeah.
And I think software developer evangelist or even more specialized, open source evangelist, I think that's such a fun sounding job.
It's never been a job I've had, but I've known some people who've done it.
And it seems like you get some of the best part of the tech community, right?
You get to bring people together to have fun, to talk about the cool, exciting stuff they're doing.
That's great.
Yeah, I mean, you link people together.
And what I like about open source evangelism is I get to focus on code and working with engineers.
And I love products and UX and even other aspects of technology evangelism.
But really working with the engineers and getting them to think of their code and their projects as products is really fun.
Yeah, that's awesome.
Raphael, how about you?
What's your story?
So I started playing with computers like around 2000.
But I only started like real programming in 2005 when I started my university.
I don't know why I didn't go into programming before because I was playing with Linux since 2002.
But I was mostly like fascinated about web.
And I discovered that everything was HTML.
So I started like learning about that.
But I don't count that as programming.
But I started programming, like programming things that were really fun in 2005.
Maybe because I thought before that programming was some kind of magic thing that you needed to have someone that like to teach you, dedicated to that.
That's really interesting.
I always felt like before I got into programming, that programming was like this special art that you had to have four years of university or six years of university to really be able to do.
It just seemed so unattainable to me in the beginning.
But then it turns out it wasn't, right?
Yeah, it's a growing story.
Yeah.
I thought that I needed someone and I didn't have anyone in my family or I didn't have any friends that were like into programming or into computers as much as I was.
So I just was doing my stuff myself and reading blogs online and things.
So but when I started programming, I got really excited.
And like in the first two weeks, I was learning Pascal at that time.
And the first two weeks, I just wrote this poem in the console.
My professor was really impressed and it was really cool.
Since then, I just got crazy and I really liked everything that I was learning.
And then I had to find a job quickly because my parents didn't have money to pay for my university in Brazil.
So yeah, I'm from Brazil.
And then I found a job in the first year of university.
And I was working with Java at that time because in my hometown is not a big city.
So I had only like job positions in Java.
And then in 2007, I discovered Python.
I was just looking for like a easier or more like concise way of writing code.
And then I found Python.
I was really happy.
Like I really like it.
I found it strange like this spacing and like indentation to define blocks in Python.
But then I just got over it and I really like Python.
I started loving it, but I couldn't work with that professionally at the time.
And then in 2009, I had the opportunity to like create my own company.
Someone just contacted me and said, hey, I have this idea.
Do you want to work with this with me?
And then I said, okay, yeah.
And I started to work with Python for web development used in Django.
And it was really cool.
And since then, I just mostly have been working with Python.
I worked with Ruby for like two years recently.
But it was just an adventure like in another language to get to know more about different
communities.
But I really like Python.
And I decided to like get back to Python.
And this year, I joined Zalando.
And I started working with Python again.
And I really like it.
Oh, yeah.
That's a cool story.
I think a lot of people get freaked out by the white space, the significant white space
and the indentation.
You're like, you know, especially if you come from a...
Just two up.
It's totally a...
It's a different way of thinking, right?
Normally, you're used to other languages, C languages, JavaScript-y languages that have
curly braces and semicolons and all this formality in the language that's extra symbols in the
language, I guess.
And they just seem required when you learn programming.
But then if you go and learn Python, if you learn Python first, I suspect it's different.
But if you go and then learn Python, you're like, well, how can it work without all these
support symbols?
But it takes about a day.
And then you're like, I don't miss those anymore.
Yeah.
I think I started understanding more when I started like getting into parsers and writing,
like trying to write compilers and things.
I really like this.
Like language, like creation things.
And then after I got some experience, I studied that in university and I started doing some work
myself on that.
I discovered like, OK, yeah, you can just like space to define blocks.
And it's not that hard.
And then I understood fully in this Python thing.
And it's actually better now.
I feel like it's good that you can just write less and have more power when you write something.
That's why I like it, too.
I mean, I've done coding in Python, especially with Django Girls.
They've got great workshops.
Yeah, Django Girls are great.
Yeah.
So I did their weekend make a blog from scratch.
Oh, nice.
And it was really, really quite fun.
But I think for somebody who likes to be sparse with language, it's great.
And also, I think, I don't know if anybody has ever done a talk or a paper on like the white space of Python,
like what it means philosophically, because there's nothing there, but there's everything there.
You know, I'm sure like somebody could have a lot of fun with something going on.
Yeah, that would be a cool, like, language philosophy talk.
Yeah, that's awesome.
Yeah.
Free conference talk idea for anyone who wants to pursue it.
There you go.
Yeah, I think there is a lot of things online about that.
Yeah.
I'm not sure.
But I'm sure I read things about that.
Nice.
Yeah.
Many people have the same practice.
They have the same experience.
Yeah, that's cool.
I think, you know, you said Django Girls.
And I think one of the things that's special about Python and open source is the community is just so supportive and enthusiastic.
Mm-hmm.
It's huge.
I remember I had a PC once, and I had to download all of these little components, like Sigwin.
And it was just, you know, on a Mac, it's so simple.
And then my computer was old and screwed up, and I brought it to this meetup.
And this poor guy, he sat there for like half an hour, 45 minutes, and basically was just trying to help me download every little crumb to get us closer to home.
We didn't actually get there, but it got far.
That's too bad.
It was a piece of crap computer.
It's been really hard on Windows traditionally to do Python, but it's getting better, actually.
You know, the guy's one of the Python core developers, Steve Dowers, works at Microsoft, and he's reworking.
He reworked, I think it's probably a continuing project, the installer.
So things install a lot better at work.
And so it's a better story these days.
But, yeah, it's still tough.
So let's talk about Zalando a little bit, just the background of it.
So a lot of people probably haven't heard of it.
What is Zalando?
Yeah, so a lot of people in Europe have heard of it.
But as an American, you're American too.
Yeah, I didn't know about the company until my former colleague had started working here as the VP of engineering.
So he's basically the head of engineering for the company.
So Zalando is Europe's leading fashion platform.
And so it's in 15 countries in Europe.
Just today we got new figures.
So we have now more than 19 million active users, more than 11,000 employees.
So about 1,300 plus are tech.
And we're based in Berlin.
We have tech hubs.
This is just for tech, not just the whole company, but for the department.
We have tech hubs in Dublin, Helsinki, a couple other German cities.
So the company has been growing like crazy.
When I got here, the tech team was maybe 650.
So that was just 18 months ago.
Wow.
So it's almost doubled, huh?
Yeah, and we didn't have a Dublin office or a Helsinki office.
We've acquired a couple of companies to build ourselves out as a platform for real.
So we have ad tech happening now and lots of content features coming up.
I mean, it's quite a...
That's really cool.
Yeah, that's quite a powerhouse.
So you guys, your major product is sort of online fashion stuff, right?
So if I want to buy clothes or like a cool suit or slacks or something like that?
Right.
So we work with all of the major brands you're familiar with.
Any household fashion brand, you're probably going to find it on our website.
And we went public two years ago too.
So that was a nice success.
Yeah, that's cool.
That's really cool.
So is it a technical challenge, both the software development side and carrying this open source
message when you guys are growing so fast and acquiring other companies that maybe have
different approaches?
Oh, sure.
And if you think about...
We're very international in our tech team as well.
So you have lots of different interpretations of how a tech team should work and what agile
is.
And some of our engineers, they've never really worked in an agile environment.
And so when you're growing that fast and you're trying to scale so quickly and work in an agile
way, it's very interesting.
This company was not always agile.
There was a shift last spring.
So spring 2015 towards this mindset called radical agility.
And this is where we officially introduced autonomous teams and mastery and purpose.
So the pillars are based on Daniel Pink's drive, which was where autonomy, mastery and purpose
comes from.
Daniel Pink has a really cool book and way of thinking.
So we basically adopted that and revamped the tech organization.
I mean, some teams had already been working in this fashion, but not department wide.
And so we said, OK, teams, you're autonomous.
And then now you're also going to have twice as many teams within 18 months.
And we're still growing.
So, yeah, there's all kinds of interesting learnings and experiences that you get when you
when you subject yourself to something so courageous.
It really is courageous for the tech leadership to take such a change on because you just don't
do it overnight.
You know, when I heard the first time about Zalando, it was just a website where you could
buy clothes and stuff.
And many people here still have this idea that Zalando is just, oh, it's just a shop.
It's just a shop online, a website.
But when I got here, I discovered that there is much more than just a website, a shop where
you can buy things like Zalando have the Datware warehouse, like where they store all the
clothing, take pictures of every article, like every piece of clothing and to put in the
website, tweet the photos.
So there is a lot of things that happen behind the scenes to this website to work.
And all of this is developed in-house, like the technology for all these levels, let's say.
And then when I started here, I discovered that and I was like, whoa, yeah, there is a lot
to do here.
Yeah.
It's not just a website.
Yeah, that's really cool.
You guys have the whole sort of web property of a bunch of API things going on.
You have some machine learning.
We're going to dig into all those things in time.
But yeah, there's definitely a bunch of cool stuff happening there.
Laura, you talked about what you do at Zalando with the open source evangelists and project
management and stuff like that.
Raphael, how about you?
What are you working on there?
Yeah.
So I currently work at the continuous delivery team.
So my team, there is like three sub teams in the team I work.
But basically, we maintain the continuous deployment for other things, like tools around that and
jenks.
So each team have Jenkins instance to run tests and like deployment jobs.
So currently working, like creating these tools to enable teams to deploy easier, like and automatic.
So they don't need to manually go to the machine, like SSH to the machine to make a deploy or anything
like that.
So we just use some tools.
So we have some open source tools like Senza and like all the things that we use to deploy.
And I also work in some open source projects at Zalando that support like that we use to create
those tools.
So connection is one of those projects.
Yeah.
And basically, that's what I do.
I develop software here.
And I also support teams also in like helping them.
Like they come to me.
They sit next to me and say, hey, Raphael, I cannot deploy.
Like there's a problem here.
And I see if it's a bug or if he just missed using the tool.
Sure.
Oh, that's really cool.
And I saw that you guys are using a lot of interesting container technologies.
So are you using Docker?
Yes.
Basically, like our applications that we deploy in production, like we use AWS CloudFormation
API.
And like we have infrastructure around AWS, which is called Stubs platform.
It's completely open source.
Like there's many applications that work together for deployment.
And yeah, we use Docker as a packaging format for the applications that we have.
And then we have like our one Docker repository, which is P1.
So we push the image there.
And we use AWS CloudFormation API to like create the whole stack of the application.
Like the whole stack when we release a new version of the application.
And then we just switch the traffic to this new stack.
So yeah.
And there is other tools to access the machine.
And everything is logged.
So you know, like, you know, like, who accesses which machine for what and which time, in what time.
And this is very important for traceability and for compliance here in Europe.
Yeah.
Of course.
How many different systems do you have running in AWS?
It must be a ton, right?
Yeah.
There is a lot.
I don't even know.
Yeah.
How do you guys keep track of that?
Each team have their one AWS account.
And we have one service that like in this Stops platform, we have one service that crawls like all the APIs that we have.
Because like all applications, they are registered in one application that like one of the applications of Stops that manage the other applications, let's say, is called Heal.
Yeah.
So you've got like an app to manage your apps.
Okay.
That seems pretty standard in Docker though, right?
Because it's hard to know what is where.
Yeah.
So here we have like a central point where we register all applications.
So from that, you get access, like your application can get credentials to access Amazon and to access other applications endpoints using OAuth 2.
And also these applications manage the versions for like the new versions of each application.
And there is another tool that crawls all the endpoints that are resisting this queue.
That's the name of the application where we register.
So basically you can make an API call to this crawler.
And yeah, it will list to like all endpoints that we have.
I see.
So it does kind of like a service discovery thing for you.
So you might start by saying, I want to talk to the credit card service.
Where is it?
Oh, it's over here.
Okay.
And then you go make a secondary call to that, something like this?
Yes.
And we use like, we make extensive use of Swagger, open API definitions for every application.
We create like every application that use, that we have APIs for that.
And all the definitions, like the Swagger definitions, they are like in an open endpoint.
So we can describe like and know what API is waiting, like call or like what are the parameters and everything.
And we have also a bunch of tools around Swagger and connection.
It's one of these tools.
Yeah.
And this thing, Stoops, if you go, it's stups.io.
And a lot of the components there are made out of Python.
Like Raphael's team is currently working on Senzo, which is part of the Stoops ecosystem.
They have this project called Lizzie that also is like works with Stoops.
Raphael can explain it better for you.
But a lot of that is Python, but also Java.
And there's some closure, but.
Yeah.
Everything that I'm talking about here is in this Stoops.io and everything is open source.
So you can just find it online.
The documentation is online.
Oh, that's really cool.
Yeah.
And it's really well documented.
And it looks like it's really built to manage this type of set of applications within AWS.
Right.
Like it's built on cloud formation and cloud trail and all those different types of things.
Right.
Yeah.
And they're built.
They're based around making.
So the idea of autonomy, right, is factored into the way that Stoops is architected.
So if you have every team with their own AWS account, then Stoops helps those teams.
Okay.
Yeah.
Work autonomously.
But also helps us to consolidate a lot of this information flying around with all the different applications.
And then if there is some sort of violation, Stoops has a mechanism for helping us report those and track them so that teams can fix.
Okay.
Yeah.
It's a way of managing what the teams are doing.
Like we have this full stop application that checks the cloud trail of the AWS accounts and then verify if each team is like following the rules.
We have like rules of play here at Zalando.
We have to follow these rules, like basically rules like of software development, like some best practices.
And some of these practices are verified using this tool full stop automatically and it generates violations for the team.
So it's like an alert and the team knows like, oh, I forgot to create a new version for this application.
Or I forgot to like enable the swagger definition and point in my application or something.
So it's really useful.
And then it gets reported to your turn, which is like this fun.
And you can go and search for your violations by your team.
I see.
Wow.
This is really fascinating.
That's quite a system that you guys have in place there.
And the integration with swagger, which we can talk about in a little bit, is also really nice.
So you can discover it in a meaningful way, not just know that it exists, right?
Yeah.
Okay.
Awesome.
I'll definitely link to that in the show notes because that's a cool project.
Mm-hmm.
This portion of Talk Python is brought to you by Hired.
Hired is the platform for top Python developer jobs.
Create your profile and instantly get access to 3,500 companies who will work to compete with you.
Take it from one of Hired's users who recently got a job and said,
I had my first offer on Thursday after going live on Monday and I ended up getting eight offers in total.
I've worked with recruiters in the past, but they've always been pretty hit and miss.
I tried LinkedIn, but I found Hired to be the best.
I really like knowing the salary up front.
Privacy was also a huge seller for me.
Sounds awesome, doesn't it?
Well, wait until you hear about the signing bonus.
Everyone who accepts a job from Hired gets $1,000 signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the signing bonus to $2,000.
Opportunities knocking.
Visit Hired.com slash Talk Python to me and answer the door.
Vivi, Lori, go first on this question.
What are some of the real technical challenges you guys have at Zalanda?
Well, I think we talked about the scalability.
So that's one.
You know, when you're growing a team so quickly and how do you get everybody on board?
And also, how do you make sure that the team ingredients are right when you're moving so fast so that you have your balance within teams of senior, junior, front end, back end?
I mean, when you're coming from a more command and control background, like a lot of the teams were when radical agility went live,
you're talking about engineers doing a lot of the teams of engineers.
And so, you know, you're talking about engineers doing a lot of functional tasks and seeing themselves as the back ender.
So why would I want to talk about the team?
You know, about API calls and a lot of the team?
And so, you know, so that's something that we're actually working on more recently.
We're starting to we've rolled out an intersource pilot.
So we've rolled out an intersource pilot.
So not just doing open source for the world, but also internally because we have services and libraries and other stuff that we can't really release publicly.
Either it's too, too embryonic or it's just really tightly connected to what we're doing and it wouldn't provide much value to the world.
We used to just kind of release a lot of stuff online, too, which is partly explains why we have less open source on our dashboard than we did because we were kind of releasing stuff.
Because radical agility was just very exciting for a lot of engineers.
Like they get to finally like do open source.
And so they just went to town.
And now it's sort of like, OK, what is the purpose?
Bringing that idea of purpose back into the work.
And so if the purpose is to serve us, you know, we probably should just keep it on GitHub Enterprise and work on it ourselves.
But, you know, ourselves isn't just our own team.
It's the other team down the hall and the team in Dublin and the team in Helsinki.
So we're really pushing this idea of inner source so that we can foster more collaboration internally.
And over time, like you see, we have some repos where one engineer makes 600 commits and the next engineer makes maybe 100.
Right.
So there's this team imbalance with inner source.
If you have more eyes on your work, more people asking questions, maybe making contributions.
And hopefully over time, you start to see the workload balancing out and the knowledge that comes with making a service or library components starting to get more distributed around the teams.
So this is a challenge because, you know, some teams are more ready for it than others.
Right.
Like, yeah, of course, people don't want anyone to look at their code because maybe they're afraid of being that it's bad.
Right.
So another challenge in all of this growth is making sure that you're reinforcing to your developers that they have the right to make mistakes and that they're here to learn and also to learn from their mistakes and get better at coding, get better at reviewing code and all of those other parts of the engineer's job.
Yeah.
Okay.
Yeah, that's really cool.
I'm a function.
I'm a robot.
I work on the database connection part or whatever.
Yeah.
Exactly.
Yeah.
So one of the primary goals of the whole agile thing in its origin was about this creating cross-functional teams and learning more vertical slices of the app than just being stuck on your little part.
And you talked about switching to radical agility and that's based on Daniel Pink's work, which is his whole motivation thing is amazing.
But can you talk a little bit about what makes radical agility different than, say, Scrum?
Like, what is it like to actually do radical agility?
Sure.
So with Scrum, it's sort of your ceremonies, right?
You have the Scrum process and you have the sprint and you have the certain number of meetings and it's pretty straightforward.
You know, it's your start, your check-ins, your end and your retrospective.
The team I'm working with has more of a Kanban approach.
So I let them choose the backlog.
So they order the tasks that they want to work on.
They rate their priorities and we do a daily stand-up, but we don't have, like, fixed periods of time.
Like, we're not doing a month long.
We're just checking in regularly to make sure that the work gets done and keeps flowing.
But there's also Scrum elements in that.
So that's just with my team.
But if you go down the hall, they may be working in a Scrum setup, like, to the book.
You may go down the other hall and you may see a team that's doing some kind of Scrum waterfall Kanban mixture.
I mean, every team is sort of at liberty to figure out what works best for them because there's just really no cut-and-dried.
Scrum works for everyone.
Or Kanban works for everyone.
Teams have different personalities.
They bring different ingredients to the table.
And really what autonomy means is you find something that works, that helps you deliver, and you iterate on that.
And it doesn't have to be any sort of fixed thing.
I mean, you start talking about fixed systems, then you're counter-agile.
Yeah.
So that's – it's abstract.
And it's hard to – it's part of that doesn't happen overnight thing.
Of course.
It seems to me like one of –
It's a lot of iteration.
Yeah.
It seems to me like one of the things that's sort of core to Daniel Pink's work is about autonomy.
And he's done some really interesting experiments and other – you know, brought together other experiments around sort of when you're doing knowledge work, what makes you the happiest and the most productive.
And it's not the biggest pay increase or anything like that.
It's about autonomy, right?
Like you get to control your future.
So it sounds to me like these different teams kind of get to have a lot of say in how they work day to day.
Okay.
Cool.
Yeah.
I think if you go to each team, here is all in the world differently.
And like I really like to work in my team because we don't have a lot of bureaucracy.
Like we have like stand-ups every day.
It's just like to check in and see what – if you need some help or if you're stuck with something else that someone can help you.
But we work kind of like I would say like open source.
Like we really work with GitHub Enterprise and GitHub.
Like it's where our projects are.
And like we have clients like Summers here, like users of our applications.
So they open issues there in the repos.
And then we just have these plannings every Friday that where they say like, okay, this week more or less next week we will work on those issues.
And then we just assign the tickets and work on it.
And there's no overhead of what meetings.
And we just sit, do our work, send up a request, send a link to people, say, hey, could you please review this?
And we just basically work in this GitFlow thing and it's really good.
I feel really comfortable work this way.
Yeah, that's cool.
The whole GitFlow style is really quite fantastic.
So let me put the question to you, Rafael.
Like what are you – from what you're doing and where you live in the whole technical space, what are the biggest challenges you see technically?
Yeah, like right now I would say that is making the teams understand how our architecture work, like how our tools work, like these stops and how to use it properly to make them work faster.
So right now I have like the biggest challenge now I would say that is spreading the idea on how to use and making the documentation better and making the applications work.
Because I think we developed really good tools and we need to improve them because like we are changing.
And there's a lot that we did before that could be improved now and I'm just like refactoring some code, like some old code that we had and making it work faster or work better and give better feedback to the users.
And yeah, I think making this open source idea more internal, like Apple, like Laurie said about in-a-sourcing, like is more about like spreading how our projects work and make people use and be autonomous to just read the documentation and start working.
So we really work developing tools for other teams.
So I think this is very important for my team specifically and making, yeah, making the tools easy to use for the teams and make them be able to work autonomously.
I mean, one of the challenges too, just to like, when you have a team of the size and teams are really, we've encouraged people to use the tools that they want to use to get the job done.
But when, when you start to have too many tools, too many languages, too many things, then it becomes hard to, it becomes hard to intersource because you may have a great project, but one team is in Java.
The project is in Python and the Java folks are going to have to ramp up a little bit to learn Python and they may not have the time to do that.
So we've actually created a tech radar, taking a nod from ThoughtWorks who have their tech radar.
So we implemented that idea for our own team.
And so we have certain languages that are, it's all organized in concentric circles.
So we have like our approved list, you know, we want you to use these things and then sort of like on hold so that we're flexible enough to start working with new technologies as they become more useful and more popular.
And so we have a certain collection of languages we really encourage teams to use and Pythons being one of them.
But yeah.
That's a really smart idea, the whole tech radar thing.
That's cool.
Yeah.
ThoughtWorks, their thoughts work.
I don't know if they use that, but maybe they.
You just gave them a new tagline.
Yeah.
It's really cheesy, but yeah, they're probably, they're not, they probably would not want that.
So I think, but yeah.
Yeah.
Cool.
So you said that you had started out with sort of a Java monolith app and you're kind of moving more to this microservice architecture where there's more different technologies, smaller building blocks.
It's all supported by steps.
Can you talk a bit about that?
Sure.
Yeah.
So when Zalando was founded, it was like Magento, it was PBHP.
And that was fine for a little while, but then the company grew.
And so we moved to the JVM in about three and a half months.
So you can imagine, but that was like lots of work.
And that worked pretty well for about five, four years or so.
But then you have a monolith, such a huge company, such a huge team.
It just made fixing bugs, working really slow and difficult.
It held us pretty much to feature technology.
And that's not very exciting if you want to play around with different languages, different technologies, even for the hiring side.
Yeah, and as an open source evangelist view, right, like you can't easily release that as a thing to the world and to participate, right?
Because it's just one giant Java app.
Yeah.
I mean, there were Python projects coming up this whole time, right?
So we have a suite of Postgres tools that were created in Python, and some of them are about three years old.
So there was a little bit of room more in the platform infrasight to develop in Python.
There's a lot of Python developers there.
But on the whole, yeah, it was pretty monolith.
So then now with practical agility, there's this shift.
Raphael mentioned the rules of play.
One of the rules is microservices, you know, supporting and building out this kind of architecture.
And so that's where you start seeing a lot of this diversity in languages and flexibility.
And you can just rewrite stuff if you want to do it differently, you know, and it shouldn't take that long because it's a lot smaller.
Yeah, that's cool.
And, you know, you can make those things work if you have systems like steps in place to sort of bring together smoothly.
And APIs.
Yeah, and APIs.
Absolutely.
One of the big questions or decisions people are making, and it's sort of transitioning these days, but are you guys using Python 2 or using Python 3?
Yeah, so we are, like, recommending new teams to, like, they are creating new projects to use Python 3.
Python 3.5 specifically, like the latest version.
And, yeah, most of the teams use Python 3.5.
But we have some old projects that use Python 2.7.
And some projects, some applications that are developed in Python and run in our data center.
And in our data center, we can just deploy applications with Python 2.7.
But the idea is that we want to shut down the data center very soon.
So, and migrate everything to AWS.
And then the teams will be able to migrate fully to Python 3.
But, yeah, mostly we recommend our new projects are in Python 3.
Yeah, that's really cool to hear.
Do you think that the microservice architecture and the API architecture made that more possible?
Like, there's not some huge million-line Python 2.4 version?
Yeah, definitely.
Yeah.
Like, having microservices instead of a big monolith application makes it easier to just replace the old application,
just fix or update the code that we had before to be compatible with Python 3.
And take advantage of the new libraries and integrations in the standard library of Python 3.
So we can just even, like, reduce the dependencies and just have a more concise code.
Yeah, that's cool.
We all want to ship our software faster, respond to user requests quicker, and build an edge on the competition.
But the faster you go, the more likely a bug or issue will slip by and cause your users grief.
I have the same tradeoffs with my Talk Python websites and infrastructure.
That's why I use SnapCI.
Every time I check in at GitHub, SnapCI springs into action.
A clean copy of code is pulled from GitHub.
A Python 3 virtual environment is created.
All the packages and dependencies are installed.
The unit tests are run.
Finally, I'm notified in Slack and a menu bar on my Mac about the outcome.
That way, I know it's safe to ship a shiny new version of my web app.
Ship your software faster with a 30-day free trial at snap.ci slash Talk Python.
So let's talk about some of the open source projects you guys have going.
You have your own GitHub pages section.
So, Zalando.github.io.
And in there, you have a really cool, you call it a dashboard, I guess.
A really cool dashboard of all of your open source projects broken down repositories by language.
And there's a bunch of cool stuff.
So, first of all, how did you create that page?
Do you guys know?
In-house, it started as an onboarding team, an onboarding project.
So our onboarding is pretty intense because every month we're adding dozens of new folks to the tech team.
So we had a system, a program for a while where the newbies would work on something for part of their onboarding.
And so the dashboard came about as that.
And then in May, we made some fixes with our UX designers.
And it was a different team just redesigned it and added the search feature.
And we changed the formula a little bit to reward activity and external contributors and stars.
So, like, you'll see Connection, which is Rafael's main project that he's working on.
It's at the top project.
Yeah, way to go.
That's awesome.
So this is really nice, a really nice way to showcase what you're doing.
There's a lot of companies that, you know, if you set up an organization in GitHub,
then you automatically get some kind of like this, a little bit, but just as a GitHub profile page.
But this is really nice.
So I was thinking, like, oh, where's the automatic generator of this thing?
Because this is cool.
Yeah, we have some really talented UX designers here.
Okay.
Shout out to Gloria Ruprecht, who is one of the UX designers that did this, like, in her spare time.
Because a lot of the engineers happen to be on her team.
And so she kind of got pulled into this a little.
But, yeah, she and another UX designer, Gabriel.
Yeah, nice work.
Props to them.
That's cool.
So, Rafael, let's talk about your project a little bit.
Let's talk about Connections.
Okay.
C-O-N-N-E-X-I-O-N.
What is that?
Yeah.
So, Connections started as we were developing this tool, like, this API in Python for deploying applications.
And, actually, Juan, we started even before I joined Zalando.
And he realized that not only in this API, we would need, in this microservice, we would need to have, like, this Swagger handling and creating an API based on Swagger file.
Because, yeah, here in Zalando, we have this process of creating microservices.
You just don't, like, you started coding directly the microservice.
We have the API guild that will review the API definition, like the Swagger file.
So, if you want to create a new microservice here at Zalando, you go to the, you create your API definition, the Swagger file.
And then you go to the API guild and you show them there is some guidelines and there is some rules that you should follow when creating a new API.
And then they give you suggestions and give you insights on how to make your API look better and better for other people that are going to use it.
And then you have a definition of your whole API, even before you write the first line of code.
Yeah, that's awesome.
Yeah.
Let me just ask you for everyone's sake, because not everybody knows what Swagger is or how Swagger defines a documentation or how it can be used to actually build an API itself.
So, what's Swagger?
Yeah, Swagger is like a specification that is a standard.
There is many standards that started popping up around specification of APIs, like how HTTP requests should be made and which endpoints are available, which parameters you're waiting, which validations are, like which formats the parameters should be.
And I would say that Swagger is the one that's winning now.
And this is recently supported by the Linux Foundation.
And it's changing the name from Swagger to OpenAPI.
So, that's why sometimes I would say Swagger OpenAPI because it's changing the name.
The official name now is OpenAPI.
So, it's the version 2.
It's the latest version.
They are working the version 3.
But, yeah, currently we use the version 2.
And, yeah, it's just a way to define your API in pretty good detail.
Like, you can define the endpoints, the parameters, what are the HTTP status that should be expected by the clients.
And from this specification, you can generate code.
Like, there is a Swagger code gen.
It's a tool that you can generate code in many different languages, including Python.
And if you use the Swagger code gen, you can generate actually connection, Python code that uses connection out of your Swagger definition.
And you can just write the code that already have dictionary validated and the way you expect it, the way you define Swagger definition.
Yeah, so connection basically is a Flask, is built on top of Flask.
You give it one of these Swagger files, which is a YAML file format that talks about the various endpoints and the type of data is passed to them and so on.
And it will basically automatically set up the routing and the data passing.
And you just write the functions to actually do the processing.
Is that the right summary?
Yes, exactly.
In the Swagger file, there is like a property, like operation ID, and we use this property to assign which function should be called for each endpoint.
But yeah, exactly.
You described it.
That's really cool.
So if I created an API this way, can I go to it and like ask it for help?
If I don't know what it is, I just find the base endpoint and will it show me like some kind of documentation of what the operations are available?
Yes.
By default, like connection enables the Swagger.json endpoint where it returns the Swagger definition.
So if you have an API created using connection, this is enabled by default, but you can, of course, hide this if you don't want it to be available to anyone.
At Zalando, we have this by default enabled.
So you can inspect in your APIs and see what they expect and how you should call it.
Okay, nice.
And is there a way to get like a friendly human readable format?
Yes.
In connection, I also provide like UI for that.
There is a Swagger UI that is like a standard in Swagger projects.
And connection provides this as well in the UI.
Like you have API creating connection.
You just dash UI and you can see this dashboard.
You can also disable it if you don't want, but there is this console that you can just have.
You just have like an interface, HTTP page, HTML page where you can just make requests.
Okay, yeah.
To your API using like an interface.
Yeah, that's really cool.
And so this plays like a central role in describing and building a lot of the APIs that are in your steps.
They're deployed into steps.
Yes, yes.
We have also the same idea as connection.
Like you create first the definition and then generate and then write the code that handles the endpoints defined in the Swagger definition.
We have also similar projects for different programming languages like Clojure and Java.
And yeah.
So you can just see, you know, Zalando GitHub page.
Right.
Oh, that's really cool.
One of the challenges of these HTTP services or RESTful services is they're really nice to work with, but they're very opaque.
You have almost no way to understand what they do or how they do it unless you just, you know, go and read the docs or something.
Right.
And so having these somewhat self-documenting is really cool.
Yes, definitely.
It's very important to tell the clients like how they should call the endpoints and have these documented.
This is very important.
And you can just use this documentation, which is parsable with a JSON file to generate code and generate clients that are up to date with your API.
So connection, like the idea of using connection to have this, your server, your Microsoft using the definition of your endpoints to handle and validate the request, make it guarantees that the clients are going to call it properly.
Like that the specification, the documentation of the API is up to date with your code.
Yeah, that's cool.
You just change the documentation and you can regenerate the clients as well.
It's pretty awesome.
Very nice.
So it seems like open source is something that you guys care more than most companies, I would say.
I mean, you have like a special page showcasing all your GitHub work.
You have, you've trimmed it down to 200 repositories.
Like, so why the focus on open source there?
I think one reason is that our VP of engineering is still a developer, loves code, introduced Scala to three different companies.
And so he comes to his leadership style and what has helped create a culture where we really value the actual work of coding.
So open source is probably the best way to be able to learn quickly.
You make new projects at work.
You iterate, you innovate.
There's also the fun community aspect and how amazing it is when a little idea can turn into something so huge.
Like you might have seen Linus Torvald's TED talk or TED like discussion.
I think it was a TED conversation where he talks about how Linux and Git grew.
I mean, he's just a guy in a room.
And it becomes where this project is used around the world.
And there's this something pretty magical in my opinion.
It's also a really great way to solve your technical challenges.
If something you're working with doesn't do the job, then if you're clever, you can make your own library or component and get your job done.
So I think that it's really it's the most fun take on capitalism I can think of.
I mean, this idea that huge, extremely successful tech companies with billions of dollars can provide this way for creative, smart people to just work for the love of it.
Yeah, it's because they want to.
Yeah, it's really amazing.
I try to showcase companies that are actually building their business on open source in a way that the thing that is the foundation of their business, they're actually giving away.
It's on GitHub.
You can go get it.
And yet there are these great, vibrant companies.
I think, yeah, I think it's really amazing.
And it's really cool that you guys are giving away and making public so much of what you're doing.
Yeah, and it's a great conversation starter.
Like I did an onboarding presentation to the new hires yesterday or the day before about our open source culture and just asking who in the room has already made something.
Get these people really excited to talk about their work.
They contributed to another project.
Okay, what was that like?
What did you learn?
I mean, it's just really it's just all organic and fun.
Yeah, I'm sure it is.
Speaking of fun to work in these environments, you guys have quite a few interesting tech jobs available, right?
At tech.zalando.de slash jobs.
Mm-hmm.
You had something like 17 software jobs and 12 data science jobs with machine learning and all sorts of cool stuff going on.
So people, a lot of people out there listening are asking me, you'll send me messages like, hey, can you recommend a cool place to work or something?
Like, yeah, check this out.
That's definitely a good option, right?
Yeah.
We have all levels, all backgrounds.
It's such a diverse team.
When you think about where everybody comes from, geographically, companies they've worked for previously or if it's their first job, you know, how did they get here?
Yeah.
I really like the idea to work with people from everywhere around the world.
Like, I'm from Brazil, but in my team there is people from Poland, from Portugal, from Netherlands and from the U.S.
There is people from everywhere.
And it's really cool.
Like, it's really nice.
You have very interesting conversation, like, at the luncheon time or, like, about different cultures and backgrounds.
And it's really cool.
Yeah, that's really cool.
Awesome.
So people, check that out if you're interested in working on these types of projects.
So I just have a few moments left.
Let me ask you guys two questions that I normally ask everyone at the end of the show and whoever wants can take them.
So on the Python package index, there are over 80,000 packages that do, you know, open source packages that do so many amazing things.
Do you guys have one you recommend or that you think is pretty cool?
Yeah.
Like, we use a lot of requests.
It's a pretty known package.
But, yeah, we use a lot.
And it's really good.
Like, I really, it works really nice.
So I would really recommend if you don't know, you don't use it, you should.
Yeah, requests are pretty awesome.
And we have an engineer on our team, Henning, who, he was largely responsible for our Python work earlier on when we were the Java monoliths and didn't have too much happening with open source.
So he's got a fair number of packages up there.
So I'll give a plug for NSEnter.
It's a Python package that lets you add, enter Linux kernel namespaces with a single syscall.
So.
Okay, awesome.
He probably need it and made it himself.
He's kind of like that.
He just puts out a lot of code and lots of projects.
Yeah, that's great.
It's amazing how prolific some people are, right?
Yes.
Cool.
He's one of them.
Yeah, very cool.
And then the other question is, when you write Python code, what editor do you use?
Yeah, I personally use Emacs, but there's not many people here in the zone that use Emacs.
Like, we have a guild and there is a few people there.
But most of the people that work with Python here, they use PyCharm.
Okay, yeah.
PyCharm is definitely a good one.
Emacs, I would say, is quite popular out there from the people I've interviewed.
So, yeah, that's cool.
I like Adam.
Yeah.
Adam works for me.
Yeah, I think Emacs is like, if you really want to sharp your tool, like, I really like
to spend time just configuring my editor and seeing it working better and having new key
bindings that work, do magical things for me.
Okay.
Yeah, that's cool.
Yeah, Emacs is great for that.
And yeah, Adam, I like Adam as well.
Yeah.
Sublime Text also does the job.
Yeah, very cool.
I'm not too picky on features.
It's like bare minimum, but I think both are so very loved by people who are picky about
things.
Nice.
All right.
Final call to action.
People want to get started with your open source stuff or learn more about it.
What do they do?
You should go to Zalando.
So that's Z-A-L-A-N-D-O dot GitHub dot I-O.
Look at what we have.
Poke around.
See if there's something that looks interesting.
Definitely try out a connection.
Check it out.
See if there's some feature or bug you want to fix.
Ping Raphael.
He'll probably be the one responding to you if it's not Jao.
We have a bunch of open source features there.
You can just pick one and work on it.
And there's another project, too, that's pretty exciting called Patroni that's also
coded in Python.
And we're actually trying to get more folks that use Kubernetes with Google Cloud Engine
to try that one out.
But we have a lot of Postgres fans.
We have a couple experts even in Postgres.
We've been using it for several years.
And so Patroni is a template for Postgres high availability.
And you can use it with Zookeeper, etcd, or console.
And we developed it.
We have Josh Burgess of Red Hat.
He's made a couple.
Maybe I should say.
I shouldn't be.
He's made quite a number of contributions.
And has also talked about it at KubeCon.
So we're really trying to get more users of it, especially in the Kubernetes community.
Yeah, those sound like great projects.
And yeah, you guys have a ton of open source things available on your GitHub pages of links.
So be sure to link to all those things.
Lori, Raphael, it's been great to talk to you.
Thanks for being on the show.
Yeah, thank you.
Yep.
Bye.
This has been another episode of Talk Python to Me.
Today's guests have been Lori Apple and Raphael Carricio.
And this episode has been sponsored by Hired and SnapCI.
Thank you both for supporting the show.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to me to get five or more offers with salary and equity presented right up front.
And a special listener signing bonus of $2,000.
SnapCI is modern, continuous integration and delivery.
Build, test, and deploy your code directly from GitHub.
All in your browser with debugging, Docker, and parallels included.
Try them for free at SnapCI slash Talk Python.
I'm so excited to finally be able to unveil my Python for Entrepreneurs course that I told you about at the top of the show.
If you want to learn Python web development and launch an online business, you owe it to yourself to check out the Kickstarter at talkpython.fm/launch.
I hope we can build something amazing together.
You can find the links from this episode at talkpython.fm/episodes slash show slash 72.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
Stay tuned.
you
Thank you.