I'm having a discussion with a coworker about how best to design our applications, which have multiple endpoints for various functions like a public API with authentication, internal communications, and webhooks from external sources (who don't have access to the public API). We've considered two main approaches:
1. **Single Server for All Endpoints:** This method involves putting everything on one server and mapping each endpoint to a specific hostname at the network level. We'll filter out internal endpoints like `/admin/*` and set up routing rules. It simplifies K8S (Kubernetes) deployment but puts the onus on the infrastructure team to understand the endpoints and specifics of the application.
2. **Multiple Services within One Application:** Here, we would expose different ports for different functions (one for webhooks, one for internal, and one for public API). This setup would allow for clearer separation of concerns and better network isolation, as the infrastructure team would only need to map one hostname to a port without additional configuration. The downside, however, is that configuring this in K8S can become quite complex.
Both options have their pros and cons, and since we lack experience across various companies, we're unsure about best practices in this context. We've already tested both solutions, so my question is about general best practices and any experiences you'd like to share.
2 Answers
Both strategies have their place! Consider the trade-offs; do you need tight coupling because the services share a data model? How frequently are your admin endpoints used? Would independent deployment make sense? Also, think about communication with the infrastructure team about port mapping and future hires who need to understand this setup. Overall, it's about weighing the pros and cons for your specific case.
Great points! Everything's configured and documented now, and we maintain a common data model across services. It's more of an 'internal' communication situation. So I appreciate your insights, as I was also leaning towards one solution while my coworker had a different view.
Ultimately, it really depends on your goals. Ask yourself whether you plan to expand the application and which services might increase in complexity. If you're operating in a layered security approach with internal firewalls, option #1 could be a better fit, as it helps manage risk more efficiently and separates concerns clearly.
Definitely! It helps compartmentalize risks and manages access more efficiently.
Right! The service is already microservice-based, operating in a blend of microservices and monoliths. It’s not expected to grow much further. Can you clarify how option #1 provides better separation of concerns?
Exactly! You raised some excellent questions there.