Cloud Engineering Archives - Software Engineering Daily

“As the scale continues to increase, certain effects of architecture become less and less efficient.” When you spend money online, you expect a receipt to come in your email. When you register for a new web site, you need to verify your sign up in your email. These types of emails are called “transactional email” and sending these types of email at scale is a complex engineering task. J.R. Jasperson is the chief architect at SendGrid, a transactional email platform. On this episode, we discuss how email works–from the basics to the massive scale that SendGrid operates on. We also talk about email spam and fraud in detail. Questions Why is transactional email important for software engineers? What are the engineering problems associated with sending lots of emails? Where can emails “fall through the cracks” so to speak? What are the scaling issues you face and how have you dealt with them? How is scaling an email service different from scaling a high-availability website like Netflix? What did you learn from the previous “tech crashes” and how does it reflect on the current climate? What is an engineering problem around email that you would never have encountered in another business? Links Sendgrid SMTP Mail server Amazon SES Kafka Egress filtering “Nobody ever got fired for choosing IBM” J.R. on Twitter The post Scaling Email with J.R. Jasperson appeared first on Software Engineering Daily.

“SaaS, whether we want it or not, in enterprise technology or in our data centers, is coming.” Application delivery has become more complex as software architectures have moved into the cloud. Data center infrastructure has turned into code to be manipulated, and software engineering teams are adjusting their strategies. HashiCorp is a company that builds open-source software for application development and deployment. Mitchell Hashimoto is the founder of HashiCorp, and he joins us to discuss a modern approach to application delivery, and the tools HashiCorp is developing. Questions What are the problems HashiCorp is trying to solve? Why does automation become more important as infrastructure becomes more complex? What are the core characteristics to a good development process? How do the changes in the deployment process affect developers? What drives the current shift towards declarative programming? Why did you choose to build your own scheduler? What is Consul? Links Terraform Vagrant OpenStack CloudFormation AMIs Schedulers https://en.wikipedia.org/wiki/Declarative_programming Consul Service discovery Mitchell’s page The post Automating Infrastructure at HashiCorp with Mitchell Hashimoto appeared first on Software Engineering Daily.

“It’s an amazing era for software developers – we have all this amazing infrastructure behind the scenes that we can build upon.” Ten years ago, building a highly scalable image delivery service would require millions of dollars in upfront costs, and hours of work configuring hardware server infrastructure. Today, it is possible to bootstrap this type of service, with minimal investment. Today’s episode is about building a content delivery network for images and video. Today’s guest is Itai Lahan, CEO of Cloudinary. We discuss Cloudinary’s early product infrastructure, and how they have evolved as a company since then. We also talk in detail about the venture capital landscape of Silicon Valley today, and how to strategize about raising money. Full disclosure, Cloudinary is a sponsor of Software Engineering Daily. Questions How did you begin working on an image CDN? What are the common problems developers have when they are trying to serve images? What did the first architecture of Cloudinary look like? What are the challenges of building APIs and integrations for a variety of different platforms that use your service? What were the first scalability bottlenecks that you hit in the early days? Why did you switch from AWS Cloudfront to Akamai? How do you monitor system health and how are your operational teams segmented? What was the rationale behind bootstrapping your company? Links Cloudinary Carrierwave Nginx AWS cloudfront Solr Akamai WebP Amazon SQS Twilio Itai on Twitter The post Bootstrapping a SaaS for Developers with Itai Lahan appeared first on Software Engineering Daily.

“Its sort of like the old joke in computer science – what do you do when you have a problem? Well, add a layer of abstraction.” Today’s guest is Calvin French-Owen, the CTO of Segment, a tool that companies use to aggregate their analytics into once place. As Segment has scaled, the company has had to restructure its etire technical architecture. Microservices, containers, Amazon Web Services, and dev ops are a few of the topics that Calvin and I explore in our conversation, so this is a great episode for anyone who is trying to understand the relationships between those different subjects. Segment’s product unifies analytics from different services and puts them into one centralized place. Full disclosure: Segment is a sponsor of Software Engineering Daily. For most of this episode, we don’t even talk about the product, we talk about the back end engineering behind the product. Questions What tools are used to transfer data to analytics systems? Why is it useful to have a single API to fan out into all the different analytics processed Why did you embrace microservices at Segment, and why was it different from the reasons other companies have adopted them? Why are process level monitoring and program level monitoring worth differentiating? Could you explain the nuance between microservices and microworkers? How do you determine when to write a brand new microservice versus adding new functionality to an old one? How did you do an architectural rebuild while still running the business day-to-day? How should software engineering teams decide whether to build or buy certain aspects of their product? Links Redshift Mode Segment Baremetrics Why Microservices Work For Us Rebuilding Our Infrastructure with Docker, ECS, and Terraform Hashicorp CoreOS Terraform Datadog The post Developer Analytics with Calvin French-Owen appeared first on Software Engineering Daily.

“It’s Friday night and you’re basically out of the office on your way to meet with friends. And you just merge this thing and put it into production because you have that trust – that the system will capture any kind of problem.” Continuous integration and deployment are important tools for modern software development. With continuous integration and deployment, individual engineers can push code without waiting to synchronize with the rest of the team on a big software release. Today on Software Engineering Daily, Flo Motlik, the CTO of Codeship, joins us to discuss continuous integration, dev ops, and microservices. In full disclosure, Codeship is a sponsor of Software Engineering Daily, but we would be doing this interview whether or not that was the case, because Flo has a lot to say about software engineering. In this show, we get into conversations and case studies of how software teams take continuous deployment from theory into practice. Questions How does an organization without continuous integration or delivery compare to one with these processes? How should testing strategy be structured to work with a continuous deployment infrastructure? What is a continuous deployment pipeline, and why is it so important? How do you define DevOps? Where did you get the idea to start Codeship? What are the performance benefits of parallelizing tests? Links Codeship Jenkins Product Hunt Everything You Always Wanted to Know About Writing Good Rake Tasks * But Were Afraid to Asks Lending Crowd Flo’s page Sponsors Wealthfront is the automated investment service that manages your investments online. Check out wealthfront.com/sedaily to get your first $15,000 managed for free, as a listener of Software Engineering Daily. Digital Ocean is the simplest cloud hosting provider. Use promo code SEDAILY for $10 in free credit. The post Continuous Delivery and Test Automation with Flo Motlik appeared first on Software Engineering Daily.

This episode is a republication from my interview with Leslie Lamport on Software Engineering Radio. Leslie Lamport won a Turing Award in 2013 for his work in distributed and concurrent systems. He also designed the document preparation tool LaTex. Leslie is employed by Microsoft Research, and has recently been working with TLA+, a language that is useful for specifying concurrent systems from a high level. The interview begins with a definition: a distributed system is a multiprocessor system in which the time required for interprocess communication is large compared to the time for events within a single processor–in other words, it takes longer for interprocess communication than it does for a process to look at its own memory. Alternatively, a distributed system is one in which processors communicate by sending messages. Leslie goes on to talk about how he became interested in distributed systems, and describes the story behind his paper about the Paxos algorithm. The goal of Paxos is to maintain consensus in an environment with unexpected faults (otherwise known as Byzantine faults). After the discussion of Paxos, Jeff asks Leslie about his recent talk “Thinking for Programmers,” which emphasizes the benefit of having a specification prior to writing actual code. “Specification” can mean a variety of things, but predicates and next-state relationships provide a mathematical rigor that is well-suited to distributed and concurrent systems. The conversation concludes with Jeff asking Leslie about how a programmer can build the mental resolve to work through a difficult problem.   The post Distributed Systems with Leslie Lamport appeared first on Software Engineering Daily.

“A lot of our customers are kind of AWS refugees who really don’t want all the stuff amazon has, and they just want a really easy to use system that is reliable.” Operating a data center has been turned into a service. For most new companies, managing real-world servers is no longer an issue. But one exception is if your startup is a company offering the data center as a service. In this episode, Jeff and Sam talk about the engineering that goes on at DigitalOcean, and how the company differentiates itself from its competitors. Sam Kottler is an engineering manager at DigitalOcean, and previously worked at Red Hat. Questions What were my options before DigitalOcean was created? If I choose to go with DigitalOcean over AWS, what are the tradeoffs I am making? What happens on DigitalOcean’s end when I spin up a droplet on the online portal? What economies of scale could you get if you moved all droplets from VMs to containers? What happens when the server my droplet is on dies? Can you talk about a distributed systems problem that you’ve dealt with that seemed unbelievable? What’s in the future for DigitalOcean? Links DigitalOcean Google File System paper Twilio How to Debug Anything MySQL Sam on Twitter The post Engineering Cloud Services with Sam Kottler appeared first on Software Engineering Daily.

“You can have a monolith, and it can be a perfectly good thing.” Monoliths versus microservices – the architectural debate continues across the internet. SoundCloud is a popular music company that experienced the rapid development benefits of a monolith, as well as the long-term technical debt. That technical debt has since been relieved by a move towards microservices. In this episode of Software Engineering Daily, Lukasz joins Jeff to talk about the realities of moving from a monolith to a microservices architecture, and walks through the lessons learned at SoundCloud. Lukasz Plotnicki is a consultant and software engineer at ThoughtWorks, which helps clients address their software development challenges and needs. Questions What are the application requirements of SoundCloud? Is there something about Rails that lends towards apps becoming monolithic? How did SoundCloud gradually ease into using microservice architecture? How did the variety of front-end interfaces affect SoundCloud’s monolithic architecture? What is the difference between a BFF and a microservice? What are the downsides of a BFF implementation? What are the lessons the SoundCloud case study has taught you about software architecture? Links SoundCloud BFF @ SoundCloud Thoughtworks Monolithic application How we ended up with microservices The Strangler Pattern Bounded Context Domain-driven design Lukasz on Twitter The post Moving to Microservices at SoundCloud with Lukasz Plotnicki appeared first on Software Engineering Daily.

“If an engineer is doing something repeatedly over and over again, their mind is immediately going to jump to that place where it’s like ‘Okay how can I make this faster?’ or ‘How can I save myself time?’” Quora is a Q&A website where questions are asked, answered, edited and organized by its community of users. Shreyes Seshasai is the Director of Engineering at Quora. Questions Is there a false dichotomy between development velocity and code quality? What does it mean to “move fast at average”? How do you incentivize people to automate? Why does Quora engineering not have pre-commit code reviews? How do you handle testing for desktop, iOS and Android? What are Webnode and Livenode? What is the relationship between engineering and design teams at Quora? Links Moving Fast With High Code Quality Quora’s Approach To Moving Fast Sustainably Tech Talk – webnode2 and LiveNode Amazon Redshift Shreyes on Twitter Sponsors Hired.com is the job marketplace for software engineers. Go to hired.com/softwareengineeringdaily to get a $600 bonus upon landing a job through Hired. Digital Ocean is the simplest cloud hosting provider. Use promo code SEDAILY for $10 in free credit. The post Engineering at Quora with Shreyes Seshasai appeared first on Software Engineering Daily.

“If you can make a system that can survive this random failure testing, then you will more or likely survive whatever other chaotic conditions exist.” Uber is a transportation and logistics company that manages many aspects of its ride-sharing services through mobile apps and distributed technology. Uber faces unique challenges in rapidly scaling its services internationally, and at one point increased its developer headcount from 200 to over 1000 in less than a year. Matt Ranney is the Chief Systems Architect at Uber and was previously a founder and CTO of Voxer. At QCon San Francisco, he gave a talk called Scaling Uber. Questions How did technical debt accumulate at Uber in the first five years? Why do microservices offer a strategy to help alleviate technical debt? Could you discuss immutable infrastructure? What is Ringpop, and how does it help maintain state? What are the service discovery problems you’ve had while scaling? How have you “embraced the chaos” recently? Links Adopting Microservices at Netflix: Lessons for Architectural Design Ringpop SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol Jeff Dean: “Achieving Rapid Response Times in Large Online Services” Keynote The Netflix Simian Army Sponsors Hired.com is the job marketplace for software engineers. Go to hired.com/softwareengineeringdaily to get a $600 bonus upon landing a job through Hired. Digital Ocean is the simplest cloud hosting provider. Use promo code SEDAILY for $10 in free credit. The post Scaling Uber with Matt Ranney appeared first on Software Engineering Daily.