abunuwas

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.

Location: London, UK Remote: Yes (preferred)

Willing to relocate: No

Main technologies: Python, JavaScript, AWS, GCP, Docker, Kubernetes, OAuth, OIDC, microservices, APIs, DevOps, Terraform, CloudFormation, serverless, OpenAPI, GraphQL

CV: https://docs.google.com/document/d/15Tv0cAwC0LYnPqjPJObX2iNf...

Email: hello@microapis.io

Calendly: https://calendly.com/joseharoperalta/let-s-talk

Website: https://microapis.io

LinkedIn: https://www.linkedin.com/in/jose-haro-peralta/

Languages: English and Spanish

GitHub: https://github.com/abunuwas

Newsletter: https://microapis.substack.com/

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.

SEEKING WORK | London (UK) and remote

Main technologies: Python, JavaScript, AWS, GCP, Kubernetes, OAuth, OIDC, microservices, APIs

CV: https://docs.google.com/document/d/15Tv0cAwC0LYnPqjPJObX2iNf...

Email: hello@microapis.io

Calendly: https://calendly.com/joseharoperalta/let-s-talk

Website: https://microapis.io

LinkedIn: https://www.linkedin.com/in/jose-haro-peralta/

GitHub: https://github.com/abunuwas

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.

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 microservices and APIs with Python (https://microapis.io/workshops).

How can I help you?

- 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.

Feel free to drop me an email at hello@microapis.io for any questions or to discuss how we can work together, or schedule a meeting with Calendly (https://calendly.com/joseharoperalta/let-s-talk).

Finishing a book, trying to arrange a few workshops, and trying to put in some time to complete an API mocking service.

Location: London, UK

Remote: Yes (preferred)

Willing to relocate: No

Main technologies: Python, JavaScript, AWS, GCP, Docker, Kubernetes, OAuth, OIDC, microservices, APIs

CV: https://docs.google.com/document/d/15Tv0cAwC0LYnPqjPJObX2iNf...

Email: hello@microapis.io

Calendly: https://calendly.com/joseharoperalta/let-s-talk

Website: https://microapis.io

LinkedIn: https://www.linkedin.com/in/jose-haro-peralta/

Languages: English and Spanish

GitHub: https://github.com/abunuwas

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.

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 microservices and APIs with Python (https://microapis.io/workshops).

How can I help you?

- 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.

Feel free to drop me an email at hello@microapis.io for any questions or to discuss how we can work together, or schedule a meeting with Calendly (https://calendly.com/joseharoperalta/let-s-talk).

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.

Much love and happy hacking!

Forgot to say, you should also check out Chris Richardon's excellent website dedicated to microservices: https://microservices.io/

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.

I'd still recommend Sam Newman's classic Building Microservices (https://www.oreilly.com/library/view/building-microservices/...) as it describes very clearly the main principles for designing robust microservices architectures. If you wanted to learn how to migrate a monolith to a microservices architecture, you can also checkout Newman's more recent Monolith to Microservices (https://www.oreilly.com/library/view/monolith-to-microservic...).

If you want a more practical approach with JavaScript examples, I'd recommend Ashley Davis' Bootstrapping Microservices with Docker, Kubernetes, and Terraform (https://www.manning.com/books/bootstrapping-microservices-wi...).

Finally, if you wanted a practical approach with more emphasis on API integrations and examples in Python, I'd recommend Microservices APIs in Python (https://www.manning.com/books/developing-microservice-apis-w... - disclosure - I'm the author). You can download two free chapters from this URL: https://www.microapis.io/resources/microservice-apis-in-pyth...

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

That's also because of fastly, I've got this response from the Heroku dashboard:

Fastly error: unknown domain: dashboard.heroku.com.

That doesn't appear to be the case does it? Amazon sites are all working fine, at least for me

Can confirm. I almost go crazy a few minutes ago when I pushed some commits and couldn't see them appearing in the Pull Requests

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!

I created https://microapis.io to make it easier to launch API mock servers in the cloud with one click, no signup or login required.

The problem I found with most existing providers is they require you to create an account and often subscribe before you can use their services. For a quick test that's excessive overhead.

Until recently I was using prism[1] to run the mock server locally, but it's very limited when it comes to configuration and you have to install and run it locally, which again it's an unnecessary overhead when you want to run a simple test.

I've been using microapis.io for a few months now with my clients and it's proving a life saver to run integration tests and to help the frontend and the backend teams to work separately while ensuring they both comply with the same API specification.

[1] https://github.com/stoplightio/prism

I live in Europe and never experienced such a thing. Perhaps to be more specific: I grew up in Spain and now live in the UK. To the best of my knowledge, children keep catching the flu every year and passing it on to their parents, who instead pass it on to their colleagues in the office (or used to, before 2020).

This makes sense. I've always caught a flu or cold in the tube or in the office, usually from an infected parent. Last year many parents were enjoying a flu-less life while the schools were closed, only to catch it again a week after opening the schools again. I don't have kids, so last year, for the first time in my life, I didn't spend a single day sick.

That's a good point. One suspects tho that governments are more interested in getting the "proper freelancers" to be treated as employees, since they usually have higher earnings and therefore offer higher revenue possibilities. The UK is going through a similar reform process right now and lots of people are being classed as employees and therefore taking massive pay cuts. End the end, you end up with temporary workers who're taxed as employees but have almost none of the benefits of permanent employees (in the UK at least).

The link in the post is broken, this is the right link: https://www.fox5ny.com/news/florida-mcdonalds-offers-50-just...

Whoops sorry about that, don't know what happened to the URL as u posted it. This should be the link: https://www.fox5ny.com/news/florida-mcdonalds-offers-50-just...

There's a place for e2e tests that run the actual services, and a place for tests that use mock servers. As a full stack developer, I know for a fact that spinning up a service, even if it's dockerized, is more often than not a hassle. Maybe because of configuration hell, maybe because setting up the database (with the migrations, fixture data, etc.) is never a straightforward job even if it's "automated". And if the architecture requires service A to talk to service B, which in turn needs to talk to service C, you end up having to spin up way too much infrastructure (each with their own configuration and database setup hells) for just a simple test. It's not worth it, and often it's not feasible since you may not even have enough memory in your computer.

For frontend developers or data scientists who couldn't care less about the backend, going through this hassle is frustrating and there's no reason why they should go through it.

Mocks are also a fundamental part of building integrations, since they allow both backend and frontend teams to work in parallel against a specification/contract.

That said, for the real integration test, you do need to run the real services and have them talking to each other. If you can do that in your own machine, great. But often the only feasible way to do this is in the cloud.

Not at all. The author makes the assumption that "the developer experience is often poor" when working with APIs. That happens often, but not because APIs are elitist or anything like that, but because they're poorly designed and poorly documented. Otherwise, working with APIs is a bliss, if you're a programmer, it's several orders of magnitude better than working with files. Anyways, APIs are not even incompatible with files. APIs don't just return JSON or XML, any API can have an endpoint that returns a file. And the fuss about authentication/keys doesn't go away with files: if the data is protected, you've still got to provide the credentials, regardless whether the data is coming in the form of a file or a JSON document

To clarify: we tracked not only microservices but also UI deployments. We had what they now call "microfrontends"

In a previous job had tons of microservices and tons of environments, so it was getting difficult to track what was deployed where. We opted for a simple solution to this: we wrote a very simple CLI that makes the deployments and at the same time registers the deployment in a DynamoDB table. Then to get a picture of a certain environment we just had to list all services for that environment. You could also list the history of releases for a certain service in a certain environment.