Esta tecnologia permite executar blocos de c\u00f3digo de forma simples e escal\u00e1vel, sem necessidade de gerir servidores ou infraestrutura.<\/p>\n\n\n\n
Onde \u00e9 que as Azure Functions Podem Fazer a Diferen\u00e7a?<\/h2>\n\n\n\n
As Azure Functions<\/strong> destacam-se por reduzirem a complexidade do desenvolvimento e da gest\u00e3o de aplica\u00e7\u00f5es.<\/p>\n\n\n\n Isto acontece porque o Azure gere automaticamente a infraestrutura. Desta forma, as equipas podem concentrar-se no desenvolvimento das funcionalidades necess\u00e1rias.<\/p>\n\n\n\n Al\u00e9m disso, as Azure Functions permitem criar aplica\u00e7\u00f5es e microsservi\u00e7os leves, modulares e escal\u00e1veis<\/strong>, que respondem a diferentes eventos.<\/p>\n\n\n\n Entre estes eventos, destacam-se pedidos HTTP, altera\u00e7\u00f5es em bases de dados, mensagens em filas de espera e tarefas agendadas.<\/p>\n\n\n\n Por outro lado, as Azure Functions permitem a integra\u00e7\u00e3o com outros servi\u00e7os do ecossistema Azure e com APIs externas<\/strong>.<\/p>\n\n\n\n Adicionalmente, suportam v\u00e1rias linguagens de programa\u00e7\u00e3o, como C#<\/strong>, JavaScript<\/strong> and Python<\/strong>. Assim, facilitam a adapta\u00e7\u00e3o por parte das equipas de desenvolvimento.<\/p>\n\n\n\n No desenvolvimento de Azure Functions com Python<\/strong>, as equipas podem criar o c\u00f3digo localmente, utilizando diferentes ferramentas.<\/p>\n\n\n\n Por exemplo, podem recorrer ao Visual Studio Code<\/strong>, ao PyCharm<\/strong> ou ao terminal, atrav\u00e9s das Azure Functions Core Tools<\/strong>.<\/p>\n\n\n\n Posteriormente, publicam o c\u00f3digo na cloud do Microsoft Azure.<\/p>\n\n\n\n Al\u00e9m disso, a integra\u00e7\u00e3o com plataformas como GitHub<\/strong>, Azure DevOps<\/strong> or GitLab<\/strong> permite estabelecer um fluxo cont\u00ednuo de desenvolvimento, testes e publica\u00e7\u00e3o.<\/p>\n\n\n\n Neste contexto, a utiliza\u00e7\u00e3o de pipelines de CI\/CD<\/strong> facilita a automatiza\u00e7\u00e3o de tarefas essenciais.<\/p>\n\n\n\n Estes processos permitem integrar, testar e entregar c\u00f3digo de forma cont\u00ednua. Assim, simplificam as tarefas desde a verifica\u00e7\u00e3o at\u00e9 \u00e0 publica\u00e7\u00e3o de vers\u00f5es atualizadas.<\/p>\n\n\n\n Consequentemente, as equipas conseguem melhorar a consist\u00eancia e a rapidez do processo de desenvolvimento.<\/p>\n\n\n\n Paralelamente, o Azure recolhe logs e m\u00e9tricas em tempo real<\/strong>, fornecendo visibilidade sobre o comportamento das fun\u00e7\u00f5es.<\/p>\n\n\n\n Desta forma, as equipas conseguem acompanhar a execu\u00e7\u00e3o do c\u00f3digo e identificar eventuais problemas.<\/p>\n\n\n\n Al\u00e9m disso, esta monitoriza\u00e7\u00e3o simplifica o diagn\u00f3stico e contribui para uma manuten\u00e7\u00e3o mais eficiente das aplica\u00e7\u00f5es.<\/p>\n\n\n\n O desenvolvimento de Azure Functions em Python<\/strong> pode seguir dois modelos principais: v1<\/strong> and v2<\/strong>.<\/p>\n\n\n\n O modelo v1, mais antigo, recorre fortemente a ficheiros de configura\u00e7\u00e3o externos, como o function.json. <\/strong>Assim, apresenta uma menor integra\u00e7\u00e3o entre a configura\u00e7\u00e3o e o c\u00f3digo.<\/p>\n\n\n\n Por outro lado, o modelo v2<\/strong> apresenta uma abordagem mais moderna e centrada no c\u00f3digo. Neste caso, os programadores podem definir as fun\u00e7\u00f5es diretamente em Python, utilizando decorators<\/em>.<\/p>\n\n\n\n Desta forma, o modelo v2 simplifica a estrutura dos projetos e proporciona uma melhor experi\u00eancia de desenvolvimento.<\/p>\n\n\n\n A escolha entre os dois modelos deve considerar diferentes fatores. Entre eles, destacam-se a complexidade da aplica\u00e7\u00e3o, o grau de personaliza\u00e7\u00e3o necess\u00e1rio e a prefer\u00eancia por uma abordagem mais declarativa ou orientada ao c\u00f3digo.<\/p>\n\n\n\n No modelo v1<\/strong>, cada fun\u00e7\u00e3o ocupa uma pasta pr\u00f3pria e utiliza dois ficheiros principais:<\/p>\n\n\n\n Desta forma, o modelo separa a l\u00f3gica da aplica\u00e7\u00e3o das respetivas configura\u00e7\u00f5es.<\/p>\n\n\n\n Segue-se uma estrutura t\u00edpica de um projeto desenvolvido com o modelo v1:<\/p>\n\n\n\n O exemplo seguinte ilustra como implementar uma fun\u00e7\u00e3o HTTP simples no Modelo v1, apresentando de forma clara a implementa\u00e7\u00e3o do c\u00f3digo nos ficheiros __init.py__<\/mark><\/mark> and function.json<\/mark>.<\/p>\n\n\n\n Al\u00e9m disso, esta organiza\u00e7\u00e3o torna o modelo particularmente \u00fatil em prot\u00f3tipos ou projetos de pequena dimens\u00e3o.<\/p>\n\n\n\n Assim, as equipas conseguem desenvolver solu\u00e7\u00f5es simples de forma r\u00e1pida, sobretudo quando a estrutura do c\u00f3digo n\u00e3o exige uma modulariza\u00e7\u00e3o complexa.<\/p>\n\n\n\n No entanto, \u00e0 medida que a complexidade aumenta, o modelo v1 pode apresentar limita\u00e7\u00f5es.<\/p>\n\n\n\n Por exemplo, projetos com m\u00faltiplas fun\u00e7\u00f5es, l\u00f3gica partilhada e testes autom\u00e1ticos podem exigir uma estrutura mais flex\u00edvel.<\/p>\n\n\n\n Nesses casos, recomenda-se a utiliza\u00e7\u00e3o do modelo v2<\/strong>, que oferece uma arquitetura mais modular e escal\u00e1vel.<\/p>\n\n\n\n The modelo v2<\/strong> surge como uma evolu\u00e7\u00e3o do modelo anterior, procurando ultrapassar algumas das suas limita\u00e7\u00f5es em projetos mais complexos.<\/p>\n\n\n\n Neste modelo, v\u00e1rias fun\u00e7\u00f5es podem coexistir num \u00fanico ficheiro Python.<\/p>\n\n\n\n Al\u00e9m disso, os programadores declaram os triggers<\/em> and bindings<\/em> diretamente no c\u00f3digo, atrav\u00e9s de decorators<\/strong>.<\/p>\n\n\n\n Desta forma, deixam de ser necess\u00e1rios ficheiros function.json<\/strong> separados para cada fun\u00e7\u00e3o.<\/p>\n\n\n\n Consequentemente, o projeto torna-se mais organizado e o c\u00f3digo mais leg\u00edvel, facilitando tamb\u00e9m a manuten\u00e7\u00e3o.<\/p>\n\n\n\n No exemplo seguinte, toda a l\u00f3gica das fun\u00e7\u00f5es encontra-se no ficheiro function_app.py:<\/p>\n\n\n\n No exemplo seguinte, a fun\u00e7\u00e3o acionada por um Timer Trigger \u00e9 definida atrav\u00e9s de um decorator<\/em>, que especifica a sua agenda de execu\u00e7\u00e3o. Dentro da fun\u00e7\u00e3o main<\/mark>, implementa-se a l\u00f3gica que ser\u00e1 executada sempre que o trigger<\/em> dispara.<\/p>\n\n\n\n Utiliza-se logging.info()<\/mark> para registar mensagens nos logs<\/em>, uma pr\u00e1tica fundamental em aplica\u00e7\u00f5es serverless<\/em>, onde n\u00e3o existe uma interface direta para ver o output<\/em>. Os logs<\/em> permitem monitorizar a execu\u00e7\u00e3o, detetar erros e manter informa\u00e7\u00f5es de auditoria. Neste caso, cada disparo do Timer Trigger<\/em> regista a mensagem “Hello World! A fun\u00e7\u00e3o Timer Trigger foi executada.”<\/mark>, confirmando que a fun\u00e7\u00e3o correu corretamente.<\/p>\n\n\n\n Caso tenha por objetivo adicionar uma fun\u00e7\u00e3o, por exemplo, com HTTP Trigger<\/em>, a seguir \u00e9 poss\u00edvel observar como seria a implementa\u00e7\u00e3o da mesma:<\/p>\n\n\n\n Como podemos observar, o c\u00f3digo define duas fun\u00e7\u00f5es independentes no mesmo ficheiro.<\/p>\n\n\n\n Por um lado, a fun\u00e7\u00e3o timer_main executa-se automaticamente a cada cinco minutos e regista uma mensagem nos logs.<\/p>\n\n\n\n Por outro lado, a fun\u00e7\u00e3o http_main responde a pedidos HTTP.<\/p>\n\n\n\n Al\u00e9m disso, permite receber opcionalmente um par\u00e2metro name para personalizar a resposta.<\/p>\n\n\n\n Desta forma, o exemplo demonstra como v\u00e1rias fun\u00e7\u00f5es podem coexistir num \u00fanico ficheiro, sem necessidade de um main central.<\/p>\n\n\n\n Consequentemente, esta abordagem simplifica a organiza\u00e7\u00e3o do c\u00f3digo e facilita o desenvolvimento de aplica\u00e7\u00f5es com diferentes funcionalidades.<\/p>\n\n\n\n No Modelo V2 das Azure Functions em Python, os blueprints<\/em> constituem uma forma de modularizar e oNo modelo v2 das Azure Functions em Python<\/strong>, os Blueprints<\/strong> permitem modularizar e organizar fun\u00e7\u00f5es fora do n\u00facleo principal da aplica\u00e7\u00e3o.<\/p>\n\n\n\n Um Blueprint<\/em> \u00e9 uma classe que permite registar fun\u00e7\u00f5es de forma independente.<\/p>\n\n\n\n Posteriormente, o programador associa essas fun\u00e7\u00f5es \u00e0 aplica\u00e7\u00e3o principal, permitindo que o runtime<\/em> as reconhe\u00e7a.<\/p>\n\n\n\n Entre os principais benef\u00edcios, destacam-se:<\/p>\n\n\n\n A estrutura seguinte representa uma Azure Function desenvolvida com recurso a Blueprints:<\/p>\n\n\n\n A seguir est\u00e1 representado um Blueprint<\/em> simples, que cont\u00e9m uma fun\u00e7\u00e3o HTTP que responde a pedidos de rota \u2018\/hello\u2019.<\/p>\n\n\n\n http_blueprint.py<\/em> Aquando da defini\u00e7\u00e3o do Blueprint, \u00e9 necess\u00e1rio regist\u00e1-lo na aplica\u00e7\u00e3o principal para que as rotas fiquem acess\u00edveis pelo Azure Functions runtime<\/em>. O exemplo seguinte mostra como importar o m\u00f3dulo onde o Blueprint est\u00e1 definido e registar as fun\u00e7\u00f5es associadas ao mesmo numa inst\u00e2ncia da FunctionApp<\/mark>.<\/p>\n\n\n\n function_app.py<\/em><\/p>\n\n\n\n Desta forma, as rotas definidas no Blueprint ficam acess\u00edveis atrav\u00e9s da aplica\u00e7\u00e3o principal.<\/p>\n\n\n\n Al\u00e9m disso, esta abordagem permite separar funcionalidades e responsabilidades em diferentes m\u00f3dulos.<\/p>\n\n\n\n The modelo v2<\/strong> \u00e9 especialmente vantajoso em projetos com m\u00faltiplas fun\u00e7\u00f5es e complexidade crescente.<\/p>\n\n\n\n Por isso, torna-se uma op\u00e7\u00e3o interessante para equipas maiores que precisam de trabalhar em paralelo.<\/p>\n\n\n\n Consequentemente, contribui para melhorar a escalabilidade, organiza\u00e7\u00e3o e manuten\u00e7\u00e3o do c\u00f3digo<\/strong>.<\/p>\n\n\n\n Para escolher a solu\u00e7\u00e3o mais adequada, \u00e9 fundamental compreender as vantagens e limita\u00e7\u00f5es das Azure Functions<\/strong> e da sua implementa\u00e7\u00e3o em Python<\/strong>.<\/p>\n\n\n\n Desta forma, as organiza\u00e7\u00f5es conseguem tomar decis\u00f5es mais informadas, de acordo com os requisitos t\u00e9cnicos de cada projeto.<\/p>\n\n\n\n As Azure Functions disponibilizam diferentes op\u00e7\u00f5es de alojamento e pagamento.<\/p>\n\n\n\n Neste contexto, o artigo original destaca dois modelos de pagamento do tipo pay-as-you-go<\/strong>: o Consumption Plan<\/strong> e o Flex Consumption Plan<\/strong>.<\/p>\n\n\n\n No Consumption Plan<\/strong>, o utilizador paga pelo tempo de execu\u00e7\u00e3o e pelo n\u00famero total de execu\u00e7\u00f5es das fun\u00e7\u00f5es.<\/p>\n\n\n\n Al\u00e9m disso, o plano apresenta uma oferta gratuita mensal de 1 milh\u00e3o de execu\u00e7\u00f5es e 400 000 GB-segundos.<\/p>\n\n\n\n Este plano tem um limite de 1,5 GB de mem\u00f3ria por inst\u00e2ncia.<\/p>\n\n\n\n Por outro lado, o tempo m\u00e1ximo de execu\u00e7\u00e3o por fun\u00e7\u00e3o \u00e9, por defeito, de cinco minutos, podendo aumentar at\u00e9 dez minutos atrav\u00e9s de configura\u00e7\u00e3o.<\/p>\n\n\n\n The Flex Consumption Plan<\/strong> representa uma op\u00e7\u00e3o mais recente e oferece funcionalidades adicionais.<\/p>\n\n\n\n Entre elas, destacam-se as inst\u00e2ncias Always Ready<\/strong>, a maior flexibilidade na configura\u00e7\u00e3o da mem\u00f3ria e a integra\u00e7\u00e3o com redes virtuais (VNET<\/strong>).<\/p>\n\n\n\n Al\u00e9m disso, este plano pode apresentar custos superiores, dependendo da configura\u00e7\u00e3o e da utiliza\u00e7\u00e3o.<\/p>\n\n\n\n Por outro lado, permite maior controlo sobre os recursos e o desempenho.<\/p>\n\n\n\n Por isso, a Microsoft recomenda o Flex Consumption Plan para cen\u00e1rios serverless que exigem maior flexibilidade e capacidade de configura\u00e7\u00e3o.<\/p>\n\n\n\nPython e Azure Functions: A Parceria Ideal para Solu\u00e7\u00f5es Inovadoras<\/h2>\n\n\n\n
Automatiza\u00e7\u00e3o com CI\/CD<\/h3>\n\n\n\n
Monitoriza\u00e7\u00e3o e Diagn\u00f3stico<\/h3>\n\n\n\n
Estruturas de Programa\u00e7\u00e3o em Azure Functions<\/h2>\n\n\n\n
Modelo v1 vs. Modelo v2<\/h3>\n\n\n\n
Modelo v1<\/h2>\n\n\n\n
\n
Estrutura de um Projeto no Modelo v1<\/h4>\n\n\n\n
MyFunctionApp\/\n\u2502\u2500\u2500 host.json\n\u2502\u2500\u2500 local.settings.json\n\u2502\n\u251c\u2500\u2500 HttpTriggerFunction\/\n\u2502 \u251c\u2500\u2500 __init__.py\n\u2502 \u2514\u2500\u2500 function.json\n\u2502\n\u2514\u2500\u2500 XXXXXXXXFunction2\/\n \u251c\u2500\u2500 __init__.py\n \u2514\u2500\u2500 function.json<\/code><\/pre>\n\n\n\n![\"Representa\u00e7\u00e3o](\"https:\/\/b2f.pt\/wp-content\/uploads\/2026\/02\/azure-functions-python-desenvolvimento.png\")
<\/a><\/figure><\/div>\n\n\nModelo v2<\/h2>\n\n\n\n
Estrutura de um Projeto no Modelo v2<\/h4>\n\n\n\n
\nMyFunctionApp\/\n\u2502\u2500\u2500 host.json\n\u2502\u2500\u2500 local.settings.json\n\u2502\u2500\u2500 function_app.py\n\u2502\u2500\u2500 requirements.txt<\/code><\/pre>\n\n\n\n\nimport azure.functions as func\nimport logging\n\n# Criar a Function App (obrigat\u00f3rio no V2)\napp = func.FunctionApp()\n\n# Fun\u00e7\u00e3o Timer Trigger no Modelo V2\n# Executa a cada 5 minutos\n@app.timer_trigger(schedule=\"0 *\/5 * * * *\", arg_name=\"mytimer\")\ndef timer_main(mytimer: func.TimerRequest) -> None:\n \"\"\"\n Fun\u00e7\u00e3o Timer Trigger que escreve 'Hello World' nos logs a cada 5 minutos.\n \"\"\"\n logging.info(\"Hello World! A fun\u00e7\u00e3o Timer Trigger foi executada.\")\n<\/code><\/pre>\n\n\n\n\nimport azure.functions as func\nimport logging\n\napp = func.FunctionApp()\n\n# Fun\u00e7\u00e3o Timer Trigger que executa a cada 5 minutos\n@app.timer_trigger(schedule=\"0 *\/5 * * * *\", arg_name=\"mytimer\")\ndef timer_main(mytimer: func.TimerRequest) -> None:\n logging.info(\"Hello World! Timer Trigger executada.\")\n\n# Fun\u00e7\u00e3o HTTP Trigger que responde a pedidos HTTP (GET\/POST)\n@app.route(route=\"hello\", methods=[\"GET\", \"POST\"])\ndef http_main(req: func.HttpRequest) -> func.HttpResponse:\n name = req.params.get(\"name\")\n if not name:\n try:\n body = req.get_json()\n if isinstance(body, dict):\n name = body.get(\"name\")\n except ValueError:\n name = None\n\n if name:\n return func.HttpResponse(f\"Ol\u00e1, {name}!\", status_code=200)\n\n return func.HttpResponse(\n \"Por favor, envia o par\u00e2metro 'name' na query ou no corpo.\",\n status_code=400,\n )<\/code><\/pre>\n\n\n\nBlueprint<\/h3>\n\n\n\n
Principais Vantagens dos Blueprints<\/h4>\n\n\n\n
\n
Estrutura de um Projeto com Blueprints<\/h4>\n\n\n\n
<project_root>\/\n\u2502\n\u251c\u2500\u2500 function_app.py # Regista os blueprints\n\u251c\u2500\u2500 http_blueprint.py # Blueprint com fun\u00e7\u00f5es HTTP\n\u251c\u2500\u2500 outro_blueprint.py # Outro m\u00f3dulo com fun\u00e7\u00f5es espec\u00edficas\n\u251c\u2500\u2500 host.json\n\u251c\u2500\u2500 local.settings.json\n\u251c\u2500\u2500 requirements.txt\n\u251c\u2500\u2500 .funcignore<\/code><\/pre>\n\n\n\n
<\/p>\n\n\n\nimport azure.functions as func\n\nbp = func.Blueprint()\n\n@bp.route(route=\"hello\")\ndef hello(req: func.HttpRequest) -> func.HttpResponse:\n user = req.params.get(\"user\")\n return func.HttpResponse(f\"Ol\u00e1, {user or 'mundo'}!\")\n<\/code><\/pre>\n\n\n\nimport azure.functions as func\nfrom http_blueprint import bp\n\napp = func.FunctionApp()\napp.register_functions(bp)\n\n<\/code><\/pre>\n\n\n\nO Equil\u00edbrio entre Azure Functions e Python: Vantagens e Desafios<\/h2>\n\n\n\n
![\"Representa\u00e7\u00e3o](\"https:\/\/b2f.pt\/wp-content\/uploads\/2026\/02\/azure-functions-escalabilidade-custos.png\")
<\/a><\/figure>\n\n\n\nModelos de Pagamento<\/h2>\n\n\n\n
Consumption Plan<\/h4>\n\n\n\n
Flex Consumption Plan<\/h4>\n\n\n\n
A Experi\u00eancia da B2F com Azure Functions<\/h3>\n\n\n\n