The cloud isn't the right solution for everything, but I've been migrating infrastructure from on-prem to the cloud for ~10 years and it's saved money, simplified processes, and improved performance in every single case. I've also done a lot of work rearchitecting cloud infrastructure with the same effects.
It all comes down to architecture and design. Many applications aren't designed for the cloud, and of course those systems are costly and painful to run in the cloud.
When I worked as a team lead, my main concern was whether were hitting our goals as a team, and ensuring every member of the team was aligned and ready to do their job. I had a colleague during lockdown who was just not getting anything done. We'd have calls to ensure he understood his task and knew what to do. But nothing was getting done. It'd take him days to reply to a message. I'll never know for sure, but I suspect he was working another job at the same time. He didn't last long in the company.
Full stack consultant and solutions architect with over 10 years of experience. I'm also the author of "Microservice APIs" (https://www.manning.com/books/microservice-apis), a frequent blogger and speaker, founder of microapis.io, and I run a very popular series of workshops about building and securing microservices and APIs (https://microapis.io/workshops).
As an expert on microservices, APIs, and Python, I help companies deliver faster and save hundreds of thousands of dollars by introducing best practices, with great focus on automation and security. My engagements typically involve a combination of system/code auditing, finding the most optimal solutions, and upskilling/training.
If you can't get your monolith right you probably won't get your microservices right. Microservices do come with additional overhead in terms of infrastructure, integrations, and so on. There's a concept of microservices readiness (e.g. https://learn.microsoft.com/en-us/azure/architecture/guide/t...). Many organisations aren't ready to embrace microservices, and if they get into microservices before they're ready, then it's a lot of pain. There's also this misconception that microservices must be nano-services. But that's not a problem with microservices architecture, it's a problem of using microservices anti-patterns. As with everything in technology, there's no universally unique solution to all problems - everything's context-specific.
Full stack consultant and solutions architect with over 10 years of experience. Over the past years, I've helped organisations of all sizes and industries to build microservices and APIs, automate their processes, harden their platform security, and improve the overall quality of their software. In my last engagement, I helped a major international retailer build a sales forecasting application powered by ML models and crunching millions of data points. Along the way, I also helped them adopt best DevOps practices and enhance their API security implementations across the board.
- Are you struggling to implement your microservices strategy?
- Are you struggling to deliver reliable API integrations?
- Do you suspect your APIs may not be properly secured?
- Does your software need a quality upgrade?
- Would you like to adopt best DevOps practices?
If the answer to any of the above questions is yes, I'm your guy. Bear in mind I specialise in Python, so I'll be more helpful if you work with that language too.
Full stack consultant and solutions architect with over 10 years of experience. Over the past years, I've helped organisations of all sizes and industries to build microservices and APIs, automate their processes, harden their platform security, and improve the overall quality of their software. In my last engagement, I helped a major international retailer build a sales forecasting application powered by ML models and crunching millions of data points. Along the way, I also helped them adopt best DevOps practices and enhance their API security implementations across the board.
- Are you struggling to implement your microservices strategy?
- Are you struggling to deliver reliable API integrations?
- Do you suspect your APIs may not be properly secured?
- Does your software need a quality upgrade?
- Would you like to adopt best DevOps practices?
If the answer to any of the above questions is yes, I'm your guy. Bear in mind I specialise in Python, so I'll be more helpful if you work with that language too.
Hi all, author of Microservice APIs in Python (http://mng.bz/nz48) here!
I just made available for free two chapters of the book! You can download them from the link in the post. Please let me know if you encounter any issues when downloading the chapters.
The first of the chapters is chapter 2 from the book, which showcases how to build an API using FastAPI. The chapter explains not only how FastAPI works, but it also explains some useful patterns for structuring your project, ensuring you keep clear boundaries between different layers of the app.
The second chapter in the booklet is chapter 7 from the book, which explains a few useful development patterns for service implementation. It introduces the concept of hexagonal architecture, explains useful principles such as the dependency inversion principle, and patterns such as repository and unit of work.
These are really my favourite chapters from the book, and I hope you find them useful! If you do, there's a discount code at the end of the booklet which you can use to grab a copy of the book.I'd also love to hear your feedback! Really, I do!
Feel free to share the link with anyone that you think could benefit from this.
I'm very lucky to be able to work from home in my current contract, and it'll probably continue to be like this for another year if I manage to renew it. However I'm not kidding myself, I know as soon as I land a new contract I'll most likely be required to commute. A lot of people I know are already being required to go to the office some days a week, or will be required to do so from September.
The past year has been one of the most productive times of my life, both at work and outside of work, but I reckon productivity is only one of many variables that most employers take into consideration, and perhaps not the most important. I guess they don't even measure productivity by how much you do, but by how much you cost?
Overall I'd say the best book about microservices is Chris Richardson's Microservices Patterns (https://www.manning.com/books/microservices-patterns). That book will get you covered with everything you need to know about designing and building microservices, and also the various strategies you can use to integrate them. The examples are in Java, but even without being a Java dev it shouldn't be difficult to follow.
It goes without saying that there're a lot more resources about microservices, and many of them excellent, but these are the books I'd recommend to get started.
Disclaimer: I'm not the author of the article and I don't agree with it. I think this kind of approach to testing is more likely to end up with test suites that test the implementation rather than the behaviour of your software, therefore making it more difficult to refactor and improve. Would love to hear other people's opinions
I've run a few (failed) projects in the past as a solo founder as well, and my single most important learning is to keep things simple, specially when it comes to infrastructure. You want something which is super easy to deploy, rollback, and debug.
Docker in itself is not necessarily easier or more difficult to manage - that depends on your orchestration solution. If you're using it to deploy to Heroku, that's probably fine. But if you intend to use something like Kubernetes or AWS ECS, I'd rather not to as they come with significant overhead and lots of moving parts.
I'm currently managing a Kubernetes cluster in GCP for a big client, and I couldn't be more convinced that this is definitely not the kind of solution I'll use for my own projects.
Finally, although it goes contrary to what is usually recommended, at the beginning I'd personally avoid Terraform and/or AWS CloudFormation as well, as they come with their own overhead and sometimes make small changes more difficult. And it's a context switch.
I see copilot as something that could be useful for generating boilerplate or starting code. Often when using a framework or library there's some boilerplate code that has to be there for things to work fine, so instead of having to the documentation and find the relevant snippets, maybe copilot can do this for you (although they often come with CLIs that do this for you). Case in point is machine learning code, where you often find lots boilerplate setting up the models, the training, etc. Maybe copilot was developed by machine learning devs for machine learning devs?
There're very few extraordinary students who can start contributing from the start. But those students are already stars of their own, not the kind you can hire. For the vast majority, there's a very long journey from graduation to professional developer. This applies also to PhDs, and yes, also from the best universities in the world (I have those in my team often). A company that only hires junior graduates as devs is a company that doesn't take software seriously. Such companies often collapse under their own weight
From the post it's unclear whether Tesla made a signed offer, or just sent the offer without signature. If the latter, there's probably not much that can be done about it. That kind of thing actually happened A LOT last year, and LinkedIn was full of people warning you to make sure you get a signed offer before you give notice in your current job. In the middle of the pandemic, many people went unemployed because of this.
Now, if the offer was signed, I'd imagine the contract had some terms and both the employer and the employee have to abide by the terms of the contract. As a candidate, you can reject an offer in the last minute, even if you accepted it, as long as you didn't sign it. But once you sign the piece of paper, you've got liabilities. There'll be a notice period and other things. And the same goes for the employer. I guess even in the US companies have liabilities towards their employees?
I'd think if this candidate passed an interview with Tesla, he won't have much trouble finding another role. It's always more difficult when you're unemployed, but you can always build leverage by applying to multiple companies, get multiple offers, and let them compete for you. Then again, NEVER turn an offer down until you're all signed with one of the potential employers and ready to start. If you can, don't even turn the other offers down until you've already started the new job. And when you decline the offer, do so in good terms making it clear that you'd like to consider working for them in the future (you can be fired anytime).
haha true, I guess there's a general feeling of dissatisfaction with the existing tools and frameworks, they're clearly not serving our needs so we have to create our own tooling. Thanks for linking your project, it looks awesome and very mature - gave you a star in GitHub!
It all comes down to architecture and design. Many applications aren't designed for the cloud, and of course those systems are costly and painful to run in the cloud.